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ABSTRACT 

A  design  for  a  secure,  multi-user,  File  Storage  System 
is  developed.  This  design,  incorporating  a  concurrently 
developed  Security  Kernel,  provides  a  multilevel  secure 
flexible  file  storage  serving  a  distributed  system  of 
dissimilar  computers.  The  Security  Kernel  is  responsible  for 
non-discretionary  (e.g.,  classification  and  clearance) 
security  and  the  File  Storage  System  Supervisor  is 
resporsible  for  discretionary  (e.g.,  "reed  to  know") 
security.  Multilevel  security  is  achieved  by  the  controlled 
access  to  consolidated  file  storage  for  Host  computer 
systems.  Multi programming  of  surrogate  Supervisor  processes 
operating  on  behalf  of  the  Host  computer  systems  provides 
for  system  efficiency,  h  segmented  memory  at  the  Supervisor 
level  allows  controlled  data  sharing  among  authorized  users. 
System  integrity  is  independent  of  the  internal  security 
controls  'or  lark  of  them)  in  the  distributed  systems;  the 
File  Storage  System  prevents  system-wide  security  side 
effects.  5  loop  free  structure  along  with  system  simplicity 
and  robustness  are  design  characteristics. 


TAILS  Ov    CONTENTS 

I.     INTRODUCTION 9 

*.   PROBLEM  DEEINITION 10 

P.   3ACKG-R0U*JD 13 

C.  BASIC  DEFINITIONS 15 

1 .  Security 15 

2.  Process 13 

3  .   Segmentation 13 

4 .  Multiprogramming 19 

5.  Protection  Domains 20  If 

D.  SYSTEM  REQUIREMENTS 20 

II  .    DESHN 23 

A.   HARDWARE  SELECTION 23 

P.   SYSTEM  STRUCTURE 24 

1.  System  Levels 2* 

2.  System  Protocol 26 

3.  Host  Environment 27 

a.   Directory  Piles 33 

t.   Data  Files 38 

c.   Multiple  Segment  Pile  Directory 33 

4.  Host  System  Commands 33 

C.   PROCESS  STRUCTURE 47 

1.  Shared  Segments  Interaction 49 

2.  Pile  Management  Process 57 

a.   Pile  Management  Command  Handler  Module.. 57 

t.   Directory  Control  Module 53 

c.   Discretionary  Control  Module 70 

5 


d.  Segment  Handler  Module 73 

e.  Memory  Handler  Module 77 

3.   Irput/Output  Process ?0 

a.  Input  Output  Command  Handler  Module 99 

b.  File  Handler  Module 90 

c.  Packet  Handler  '  Module 94 

III.   CONCLUSIONS 99 

IV.   STATUS  OF  R2ASFARCH 99 

P.   FOLLOW  ON  WORK 100 

APPENDIX  A—SYSTEM  PARAMETERS 102 

APPENDIX  B— SUCCFSS  AND  FRROR  fOD~S 103 

APPENDIX  C—  FM/IO  COMMAND  HANDLER  MODULES 104 

LIST  0^  REF~R?NCFS 11? 

INITIAL  DISTRIBUTION 120 


LIST  OF  FIGURES 

1.  System  Conf isurat i or. 11 

2.  Protection  Domains 21 

3.  Abstract  System  View 2K 

4.  General  Supervisor  File  Hierarchy  Example 29 

5.  Virtual  File  Hierarchy 32 

6.  Logical  Directory  Structure 34 

7.  File  Discretionary  Access  Control 41 

3.   FM  Process  Modules • 5S 

9.  Mail_3ox  Segment 59 

10.  Corn  and  Handler  Module 60 

11.  Direct  ory_Cor.trol  Module <=4 

12.  Discretionary_Control  Module 72 

13  .   FM_Known_5egment_Table 74 

14.  Sesme^t  Handle7*  Module 74 

15.  Memory_Hardler  Module 75 

16.  FM_Active_S  earner  tJTable 7C 

17.  Memory_Handler  Memory  Map 72 

19.   IC  Process  Modules 81 

19.  Packet  Construction 93 

20.  IO_Comma-d_Eandler  Module 91 

21.  File_Handler  Module 91 

22.  Packet  .Handler  Module 95 

23.  Finite  State  Diagram  of  Packet  Transfer 96 


ACKNOWLEDGEMENT 

This  research  is  sponsor°d  in  uart  by  Office  of  Naval 
Research  Project  Number  NR  337-005,  monitored  by  Mr.  Joel 
Trimble. 

Special  thanks  20  to  Lt.  Col.  Roser  Schell  and  Prof. 
Lyle  Cox  for  their  invaluable  advice  and  many  hours  of 
assistance . 


I .   INTRODUCTION 

Lacv  of  data  security  is  a  ?ertral  issue  in  computer 
science  today,  ^ata  security  car  be  divided  into  external 
physical  aspects  (i.e.,  guards,  fences,  etc.)  and  irtQrnal 
systerr  aspects  'i.e.,  internal  software  and  hardware 
operations'1;  both  of  which  are  necessary  for  effective 
system  security.  The  physical  aspect  is  understood  and  does 
no*.  pnse  a  significant  problem  today.  Continued  loses  (viz., 
money,  data'  die  to  computer  'error',  illustrate  that  the 
second  aspect  of  data  security,  viz.,  internal  security,  has 
not  beer,  solved  and  continues  to  be  a  problem. 

T  h  i  ^  short coming  results  frc^  the  fact  that  internal 
computer  security  has  not  beer,  a  mandatory  design  objective 
during  hardware  and/or  software  selection  and/or  production 
in  most  (if  ^o*  all)  contemporary  computer  systems.  This 
renders  them  prone  to  security  violations  from  accidential 
or  malicious  penetrations  [Schell(l)].  Ad  hoc  attempts  to 
provide  the  necessary  system  security  in  the  later  stages  of 
the  system  design  or  implementation  have  not  ~encrally  met 
with  success. 

In  contrast,  this  thesis  presents  a  design  for  a 
multilevel  secure  computer  operating  system,  the  File 
Storage  System  i.YSS)  in  which  internal  computer  security  is 
a  primary  design  objective.  There  are  two  ?oals  "his  system 
is  designed  to  achieve:  1)  to  provide  sharing  of  data  among 
authorized  users  a^d,  2)  control  access  to  a  consolidated 
'warehouse'   of  data.  This  controlled  access  to  consolidated 
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data,  predicates  a  'star'  network  for  the  system  structure 
as  depicted  in  figure  1.  It  must  be  noted,  however,  that  the 
?SS  ca^rct  control  the  physical  security  cf  the  Host  systems 
ard  that  'Tost  systems  have  the  ability  to  circumvent  "PS 5 
security  by  direct  inter-Host  communication  links.  To 
preserve  data  security,  all  accesses  to  the  7SS  consolidated 
data  rrust  gn  through  the  7SS  for  access  validation. 

Data  sharing  anions  authorized  users  is  accomplished  by  a 
segmented  environment  which  allows  controlled  direct  access 
to  all  on-line  data.  The  Security  Kernel  'or  simply  Kernel) 
is  used  to  insure  that  non-discretionary  date  access  is 
performed  in  an  absolutely  controlled  ''i.e.,  secure)  manner. 
'See  [Coleman]  for  detailed  information  en  the  Security 
Kernel.) 

A.   PRC3LSM  DEFINITION 


'it  is  illogical  to  ignore  the  fact  that  computers  may 
disseminate  information  to  anyone  who  knows  how  tc  ask  for 
it,  completely  bypassing  the  expensive  controls  Placed-  o^ 
paper    circulation."    [Schell(l)] 

That      this      fact      is      ignored      is      demonstrated      by      the 

estimated     I??,     million      dollars      lost      yearly  by   non-secure 

computer   systems    in    the   United   States       [Denning(2)l .      It      is 

obvious        that      a      primary      problem/limitation      of      computer 

systems    in   use    f>day      is      the      lack      of      data      security.      As 

recuirements      to    store   and   access   data    by   computer    increase, 


this      problem/limitation        cannot        be 


the      seriousress      o 
ignored . 

A        system      that      can      simultaneously      provide      data      at 
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different  sensitivity  (viz.,  classification  )  levels  for 
users  with  different  access  authorizations  (viz., 
"clearances")  without  a  security  violation  is  said  to  be  a 
multilevel  secure  system.  "Because  it  is  usually  rot 
desirable  to  authorize  all  system  users  access  to  the 
highest  level  of  data  ''system  high.')  or  provide  separate 
'without  sharing)  systems  for  each  level  of  data,  a 
multilevel  system  is  highly  desirable.  \  multilevel  system 
also  allows  the  raxiTum  amount  of  controlled  data  sharing 
amor<?  authorized  users,  a  primary  eoal  of  any  lata  storage 
system. 

Previous  research  shows  that  a  viable  approach  to  the 
auestior.  of  internal  computer  security  exists.  This 
approach,  sometimes  termed  the  security  kernel  approach 
[Schell'2)],  was  introduced  by  Schell  in  1972.  It  gathers 
into  o^e?  module  all  elements  that  effect  the  system 
security.  The  module,  by  bein^  restricted  in  size,  can  be 
verified  correct  which  in  turn  allows  the  total  system  to  be 
certifed  secure. 

The  F5S  software  is  composed  of  the  Supervisor  and  the 
Kernel.  It  will  provide  a  multilevel  secure  consolidated 
file  storage  for  distributed  Host  computer  systems.  The 
non-discretionary  security  provided  by  the  Kernel  ari  the 
discretionary  security  provided  ty  the  Supervisor  will 
implement  a  wide  ran«;e  of  security  uolicies,  including  the 
standard  Department  of  Defense  (DOD)  security  policies.  Data 
sharing  is  achieved  by  a  segmented  memory  environment  at  the 
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Supervisor  level.  The  Supervisor  uses  segments  (invisible  to 
the  Host  systems)  to  construct  the  Host  files.  Multilevel 
security  is  achieve!  by  the  management  of  files  submitted  "by 
the  Host  systems  which  e^ist  at  distinct  security  levels. 
This  allows  the  construction  of  a  multilevel  secure  system 
which  is  dependent  on  crly  orQ  securp  element  of  the 
TSS — the  Kernel. 

3.   BACKGROUND 

The  dramatic  reduction  in  size  and  cost  along  with  the 
increase  in  performance  of  microprocessors  in  the  last 
decade  has  made  their  use  feasible  in  areas  that  have 
previously  hee^  reserved  for  ni^i/maxi  computers  for  rot 
computed  at  all).  Whereas  security  has  teen  notoriously 
lacking  i**  the  larger  systems,  it  has  been  no^-existent  ir 
microprocessors  to  date. 

Because  of  their  small  siz°,  low  cost,  durability,  ari, 
perhaps  most  importantly,  the  manpower  savings  induce!  ''just 
to  mention  a  few  of  many  advantages),  microprocessors  have 
hish  aupeal  for  use  in  a  military  environment.  However,  the 
military  also  has  an  obvious  need  for  security  within  their 
computer  systems,  whether  they  are  micro,  mini,  or  maxi 
based  . 

For  example,  the  Navy  is  presently  considering  systems 
for  the  ne,r t  generation  of  non-tactical  shipboard  computers 
[Smith].  They  will  be  mainly  used  for  data  processing  in  the 
areas  of: 
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Pay  and  Personnel 

Supply  and  Finance 

Maintenance . 

Cost.  siz°  a^d  speed  constraints  will  sccr  be  net  fcy 
Commercially  available  products.  Security,  however, 
continues  to  be  a  problem  not  adequately  addressed  in  any 
available  systems.  To  preserve  data  confidentiality  (not 
only  with  respect  to  clearance  le"rel  tut  also  with  respect 
to  the  current  stipulations  of  the  Privacy  *ct),  security  is 
a  necessary  part  of  any  shipbnard  computer  system.  Pay 
records.  for  example,  should  not  have  the  same  access  level 
as  maintenance  records.  In  order  to  store  records  in  a 
common  data  base  and  to  have  controlled  sharing  when 
aopropriate,  the  computer  must  be  able  tc  maintain  a 
multilevel  secure  environment. 

ThQre  are  several  possible  approaches  to  achieve  a 
secure  multilevel  environment.  The  frontal  approach,  which 
is  most  difficult,  is  to  certify  all  distributed  computers 
which  have  access  to  the  data  base  as  secure.  k  second 
method  and  the  method  adopted  for  the  FSS ,  is  to  cerfify 
only  one  element  of  the  FSS  secur° — the  Security  Kernel.  -11 
access  to  the  VSS  that  involves  non-discretionary  security 
will  be  validated  by  the  Kernel.  The  FSS  therefore 
guarantees  to  manage  files  in  a  manner  consista.it  with  the 
FSS  security  policies. 

The  design  for  the  "S3  is  one  membe"  of  a  family  of 
systems  proposed  by  O'Connell   and   Richardson   [0  'Cornell] . 
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Security,    configuration    independence,   and   a   loon-free 
structure  are  characteristics  of  this  family  of  systems. 

P.   EASIC  T)"FFI  NIT  IONS 

1 .   Securi  ty 

'lthcugh  any  viable  secure  system  includes  both 
internal  and  external  aspects,  relying  excessively  on 
external  controls  is  not  desirable  in  many  cases  due  to  the 
added  expenses  and  increased  security  risks  involved  in 
error-prone  manual  procedures.  External  controls  also  cannot 
provide  the  secure  sharing  of  data  that  is  needed  ir.  such 
applications  as  integrated  data  bases  and  computer  networks, 
primary  characteristics  of  the  FSS .  The  use  of  the  Kernel 
concept  is  a  demonstratively  effective  and  practical  method 
for  providing  the  internal  computer  security  controls  that 
are  necessary  fnr  a  secure  multilevel  system.  This  concept 
is  at  the  center  of  the  TSS  design. 

The  basic  co^.cex)*  behind  this  approach  is  that  a 
small  ucrtion  of  hardware/software,  the  Kernel,  can.  provide 
the  internal  security  controls  that  are  effective  against 
all  attacks,  (malicious  or  accidental)  including  those  never 
thought  if  by  the  designer.  (This  also  means  that  errors  in 
the  7SS  Supervisor  cannot  cause  unauthorized  access  tc 
data.  ) 

System  security  is  the  implementation  of  a  security 
policy.  This  uolicy  is  a  collection  of  lavs,  rules,  and 
regulations  that  establish  the  rules  for  access  to  the   data 
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in  the  system.  Such  policies,  such  as  the  one  established  by 
the  DCD.  have  two  distinct1  aspects:  discretionary  and 
non-discretionary  security.  Non-discretionary  security 
ex  tern ally  constrains  what  access  is  possible.  In  the  DOD 
environment ,  the  familiar  non-discretionary  security  levels 
are*  top  secret.  secret.  confidential,  and  unclassified. 
Since  most  contemporary  computer  systems  do  not  provide  the 
data  labeling  necessary  to  support  non-discretionary 
security,  all  data  is  implicitly  accessible.  In  the  ?SS, 
segmentation  allows  unioue  id ent if icat i on  and  labeling  of 
data;  non-discretionary  security  is  therefore  supported.  The 
Kernel  is  the  one  element  in  the  FS3  responsible  for 
enforcing  non-discretionary  security. 

Non-discretionary  security  involves  the  comparing  of 
the  access  class  of  a  specific  object  (object  access  class, 
■oac))  with  the  access  class  of  the  reouestor  (subject 
access  class,  'sac))  to  insure  compatibility.  In  a  DOD 
environment,  for  example,  a  person  (subject)  with  sac  of 
secret  has  access  to  files  (objects)  at  any  access  class 
eaual  to  or  less  tha^  secret.  The  relationships  between 
different  access  classes  are  represented  by  a  partially 
ordered  lattice  structure  [r'erining(  1 )  ]  .  This  lattice 
represents  the  authorized  access  based  on  the  relationships 
of  two  levels.  An  example  of  the  not— related  (making  the 
lattice  partially  ordered)  relationship,  occurs  because  of 
DCD  com.partrren tali zation  (e.g.,  secret  is  not  related  to 
secret  .nuclear ) .   The   following  accesses  are  permitted  for 
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the  relationships  represented  "by    this  lattice  structure. 

sac   =   oac   tread/write  access 

sac   >   oac   :read  accpss  ''read  down) 

sac   <   oac   : write  access  'write  up) 


sac   O  oac   : r. o  access  (sac  not  related  to  oac) 

In  each  case,  the  Kernel  must  snow  the 
identification  of  the  Host  system  if  it  is  to  perform 
correct  non-discretionary  security  checks.  Unique  system 
identification  is  provided  by  the  system  pert  number,  which 
is  hardwired,  and  known  to  the  Kernel, 

Dis cr°t i o^ary  security  provides  a  refinement  to  the 
non-discretionary  security  policy  and  is  reflected  in  the 
DOT  "need  to  know"  policy.  Computer  systems  which  have 
'ccess  Control  Lists  ('ACL  ^  associated  with  data,  implement 
this  discretionary  policy.  The  755  Supervisor  is  responsible 
for  the  System  discretionary  security  and  although  this 
aspect  of  the  System  security  is  not  validated  by  the  Kernel 
(and  therefore  rot  certified  correct),  the  validity  of  t*>e 
non-discretionary  security  is  not  affected. 

To  implement  its  aspect  of  security,  the  Supervisor 
needs  to  know  the  identification  of  the  Host  system  "user". 
This  Host  system  user  identification  must  be  passed  to  the 
7SS  Supervisor  by  the  Host  system.  Since  an  insecure  Host 
system  cannot  be  trusted  to  pass  the  correct  information, 
the  user  identification  is  only  as  prood  as  the  Host  system 
implementation,  (i.e..  ^SS  discretionary  security  is  only  as 
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good  as  the  H^st  System's  implemer. tatlon  of  discretionary 
security.)  This  implemen  tat  ion  may  be  <?ood  on  some  systems, 
(e.g.,  UNIX  [Morris])  but,  non-existent  on  other  systems 
(e.g.,  CP/M  [Digital]).  It  must  be  remembered  that  this  in 
no  way  affects  the  enforcement  of  the  non-discretionary 
security  by  the  Kernel. 

2 .  Process 

&  process  can  be  described  as  a  locus  of  execution. 
The  collection  of  locations  that  may  be  accessed  during  this 
execution  is  known  as  the  nrocess'  address  space  [Madnick] . 
A  process  also  has  the  characteristic  that  it  may  be 
executed  in  parallel  with  other  •processes,  enhancing  system 
efficiency  aH  allowing  the  separation  of  tas'rs  i^t.c 
different  processes  for  design  clarity. 

The  FSS  has  two  processes  per  Host  system.  These  are 
an  input  /output  '10)  process  for  Supervisor  to  "ost  data 
transfer  and  comrnuricat  ior.  end  a  file  management  (IM) 
process  that  controls  and  maintains  the  Supervisor  file 
structure.  Interprocess  communication  is  achieved  by  the  use 
of  even  tcour.ts ,  sequencers,  and  synchronization  primitives 
internal  to  the  Kernel  (described  later). 

3.  Segmentation 


Segmentation  allows  for  the  direct  addr°ssins  of  all 
system  on-line  information  end  the  application  of  access 
control   to   this   information.   Mote  that  direct  addressing 
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ices  not  mean  random  access  to  the  on-line  infornation.  On 
the  contrary,  access  to  sDgmerts  is  controlled  by  explicit 
memory  management  calls  to  the  Kernel  to  swap  in/out  a 
segment.  A  segment  can  "be  defined  as  a  logical  grouping  of 
information  such  as  a  subroutine,  procedure,  data  area,  or 
file.  Each  processes'  address  space  consists  of  a  collection 
of  segments.  In  a  segmented  environment,  all  address  space 
references  require  two  components,  a  segment  specifier  and 
an  offset  within  that  segment.  Segmentation  is  used  to 
provide  the  Supervisor  domain  of  each  process  a  virtual 
memory  of  limited  size.  Segments,  as  mentioned  earlier,  are 
used  by  the  Supervisor  to  construct  the  Host  files  which 
retain  the  attributes  of  segments  ''i.e.,  access  control). 

4.   Mul  tiprcgrarnmin? 


5  mul  tipr  oar^ammed  environment  is  one  in  which  mere 
tha-"  one  process  is  in  a  state  of  execution  at  the  same 
time.  These  processes  share  urocessor  time,  memory,  and 
other  resources  among  the  active  processes.  In  the  design 
for  the  "FSS ,  the  Supervisor  processes  are  mult  ipro.^rammed  in 
an  asynhcronous  manner  for  system  efficiency.  A 
mul tipro srammin^  environment  allows  the  Host  systems  to 
operate  in  a  logically  parallel  manner  which  adds  to  System 
design  simplicity  and  clarity. 

5 .   Protection  Domains 

One  of  the  "^ey  elements  necessary  for   valid  Kernel 
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implementation  is  the  isolation  of  the  Kernel  from  all 
possible  outside  influences.  This  car.  be  lone  through  the 
use  of  protection  domains. 

Protection  domains  are  used  t  n  arrange  process 
address  spaces  into  "rings'*  [Schroeder]  of  different 
privilege.  This  arrangement  is  a  hierarchical  structure  with 
the  most  privileged  domain  bein^  the  inner  most  rins.  Figure 
2   represents  the  ring  or^a^ izat 1 01  in  the  FSS. 

Protection  rin.?s  may  be  created  by  either  hardware 
or  software.  Hardware  is  nore  efficiart  but  is  rot 
commercially  available  in  microprocessor  devices  today.  Two 
state  devices  are  available,  however,  ard  by  i-plerre"" ting 
the  two  states  as  separate  rings  and  providing  for  software 
ri^g  crossing  mechanisims,  the  necessary  two  protection 
rings  can  be  created. 

D.   SYST3M  aSQUIHEMSMTS 


There  are  no  fixed  hardware  reauirements  for  the 
implementation  of  the  FSS.  System  efficiency  does,  however, 
depend  on  an  ancroioria  te  choice  of  hardware.  Two  basic 
hardware  features  that  are  felt  to  be  necessary  for  a  viable 
i^pleme" +at i nr  of  the  FSS  are  segmentation  and  multiple 
domains . 

Segmentation  is  necessary  for  access  control  a *> d  data 
Sharing.  fl  multiple  state  ' two  in  this  case)  is  necessary 
for  the  i s^lat i 0*1  of  the  Kernel  from  the  remaining  (and 
uncertified)  software. 
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Figure  2.  Protection  Domains 
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Only  the  Kernel  has  access  to  privileged  machine 
instructions  aid  controls  all  system  input /output .  It 
provides  a  segment3!  environment  in  which  the  Supervisor 
operates.  The  Supervisor  iv.  turn,  provides  a  virtual  file 
environment  for  the  TJost  computer  systems. 
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II.   DESIGN 
A.   HARDWARE  STITOTION 

A  secure  computer  system  is  not  dependent  on  the 
hardware  or.  which  it  is  implemented.  However,  as  mentioned 
above,  segmentation  and  multiple  domains  are  considered 
necessary  for  7SS  efficiency. 

Segmentation  allows  the  use  of  one  uniform  type  of 
information  object,  the  segment,  at  the  Kernel  level.  This 
simplifies  Kernel  design  ard  contributes  to  keeping  Kern°l 
size  small.  s,  segment  address  consists  of  a  segment  name  and 
offset  within  the  segment.  Although  this  addressing  can  be 
done  in  software,  it  is  faster  and  Tore  efficient  when  dore 
ir  hardware.  Hardware  can  also  simultaneously  chec>  for 
authorized  access,  a  necessary  feature  of  a  secure  system. 

Multiple  do^ai^s  are  curr°ntly  used  in  sn^e  of  the 
larger  machines  to  protect  the  operating  systems  from  the 
applications  programs.  Multiple  domains  have  rot,  until 
recently,  beer,  available  in  a  microprocessor  configuration. 
The  FSS  design  reauires  only  two  domains,  "re  for  the  Kernel 
and  one  for  the  Supervisor. 

The  introduction  of  the  Zilog  Z8000  series 
microorocessor  meets  both  the  segmentation  ard  multiple 
domain  requirements.  The  FSS  is  targeted  for  implementation 
on  the  Z?P01  segmented  microprocessor  [Ziloe(2)l  with  its 
associated  Memory  Management  Unit  (MMU)  [Zilog'l)].  The 
Z9901  is  a  16  bit  two-domain  machine  which  produces  a  23  bit 
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logical  address.  The  lQ/*\?  MMU  maps  the  23  tit  logical 
address  into  a  24  "bit  absolute  address  and  allows  the 
capability  of  addressing  up  to  128  segments  'with  two  MMU's) 
of  64K  bytes  each  ^BM-bytes  total)  in  a  two-dimensional 
memory  space.  (See  [Coleman]  for  further  details.)  RS-232 
bus  compatibility  is  assumed  for  serial  data  input/output  at 
the  hardware  level.  This  allows  tyte  synchronization  and 
byte  parity  checks  to  be  performed  at  the  hardware  level  by 
the  ?SS  universal  asynchronous  receiver-transmitter  (UART). 

B.   SYSTEM  ST?UCTU?:E 

1  .   System  Levels 

Abstraction  is  a  way  of  avoiding  complexity  and  a 
mental  tool  for  approaching  complex  problems  [Lij^stra  2)]. 
The  use  of  abstartion  allows  the  presentation  of  a  system 
design  that  is  concise,  precise,  and  easy  to  understand. 
There  are  four  levels  of  abstraction  for  the  F35  as 
presented  in  figure  3. 

Level  C*  is  the  hardware  level  aM  consists  of  the 
ZF021  microprocessor  memory  and  some  form  of  disc  storage 
(initial  implementation  may  be  with  floppy  disc). 

Level  1,  the  Kernel,  is  isolated  and  protected  from 
manipulation  raccidential  or  malicious)  by  bei^g  placed  in 
the  more  privileged  domain  of  the  ZS031.  Only  the  Kernel  has 
access  to  "system"  machine  instructions  and  controls  all 
access  to  the  system  hardware  elements  ''memory,  disc).  The 
Kernel   provides   a   segmented   environment   in   which    the 
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Supervisor  operates. 

Level  2,  the  Supervisor,  operates  in  the  outer  'less 
privileged )  domain  of  the  Z8?01.  It  has  access  to  "normal" 
machine  instructions,  but  must  go  through  the  software 
Gatekeeper  [Coleman!  of  the  Kernel  to  get  access  to  memory 
(viz.,  segments)  and  iisc  storage.  The  Supervisor  provides  a 
virtual  file  hierarchy  to  each  Host  system  for  file  storage. 
In  order  to  manage  the  file  hierarchy,  surrogate  processes 
(input /output  (10)  and  file  management  (FM))  are  assigned  tc 
each  TJost  system.  These  processes  act  on  the  reauests 
submitted  by  the  Host  computer  systems.  *11  processes  are 
created  at  system  generation  time  and  are  not  created  or 
deleted  in  a  dynamic  manner. 

Level  3  consists  of  the  Post  computer  systems.  These 
systems  a~e  hardwired  tc  the  Z8001  in  the  FSS  design.  Each 
port  has  a  fixed  access  level  so  that  if  a  multilevel  secure 
Host  desires  to  handle  data  at  two  levels,  it  must  have  two 
connections  to  the  ^SS.  'Note  that  if  the  Host  is  not  a  true 
secure  multilevel  Host,  and  dees  have  multiple  connections 
with  distinct  levels,  then  the  TSS  security  constraints  are 
ci  rcumvented . ) 

2 .   System  Protocol 

Protocols  are  formal  specifications  which  constrain 
data  exchange  between  systems  and  the  PSS.  These 
specification?  allow  the  FSS  to  achieve  bounded,  deadlock 
free   and   fault   tolerant   communication.   To   organize  and 
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simplify  protocol  design  in  the  FSS ,  protocol  is  logically 
divided  into  a  hierarchical  structure  of  two  interacting 
layers.  Level  1  protocol  handles  packet  (described  later) 
synchronization,  error  detection,  and  command  type 
determination.  Level  2  handles  the  repetitive  activity  of 
data  transfer. 

Data  and  commands  are  transmitted  between  ^SS  and 
lost  via  fired  sire  packets.  Packet  synchronization  is 
necessary  for  Host-rSS  communication.  Error 
letection/correction  is  closely  related  to  the  problem  of 
packet  synchronization;  packets  not  in  synchronization  will 
not  he  correct.  The  converse  is  not  true,  however,  k 
synchronized  packet  may  contain  transmission  errors.  There 
are  several  methods  fnr  error  detection/correction 
[Hamming].  A  design  choice  of  a  simple  check  sum  per  packet 
'to  detect  packet  errors)  was  made  in  the  interest  of  Svstem 
simplicity.  If  an  error  is  detected  in  a  packet,  the  Host 
will  be  reauested  to  stop  packet  transmission  and  to  be^ir 
a^ain  with  the  packet  in  which  the  error  was  detected.  Cf 
course,  the  FSS  must  be  able  to  orovide  the  same  service. 
This  retransmission  upon  error  detection  strategy,  combined 
with  the  byte  narity  checks  performed  at  the  hardware  level 
by  the  UART,  will  provide  the  error  detection/correction 
scheme  in  the  initial  FSS  design. 

3.   Host  Environment 


The   job  of  the  FSS  is  to  nrovide  a  service,  viz.,  to 


store  files  in  a  secure  data  warehouse  .  The  files  are 
submitted  by  various  Host  computer  systems.  The  virtual 
environment  provided  the  Host  systems  is  therefore  a  primary 
design  consideration  of  the  overall  FSS  design.  Design  soals 
are  to  make  this  Host  environment  simple,  easy  to  use  and 
understand,  efficient  and  robust  . 

The  center  of  the  Host  environment  is  the 
hierarchical  file  structure  maintained  by  the  Supervisor  of 
the  FSS.  This  file  structure  is  a  tree  organization  which 
facilitates  design  abstraction  (virtual  file  systems  per 
Host)  as  well  as  file  system  searches  via  tree  traversal. 
Figure  4  illustrates  the  overall  logical  structure  of  the 
Supervisor  file  system. 

A  file  can  be  defined,  in  the  case  of  the  FSS,  as 
one  or  more  Supervisor  segments  grouped  tosether  for  the 
purpose  of  access  control  ''security),  retrieval  (read),  ari 
modification  (write)  [Shaw].  In  the  FSS  the  file  is  the 
basic  unit  of  storage  at  the  Host  system  level. 

The  hierarchical  file  system  contains  two  types  of 
files:  1)  data  files,  and  2)  directory  files.  Beth  file 
types  are  constructed  from  segments  'invisible  to  the  Host 
systems)  at  the  Supervisor  level.  The  characteristics 
usually  associated  with  a  segmented  environment  (Supervisor 
level)  such  as  data  sharing  and  access  control,  are 
transferred  to  the  file  environment  (Host  level)  by  the  FSS. 

The  Host  system  environment  consists  of  a  virtual 
file  hierarchy  maintained  for  each  Host   system   (i.e.,   one 
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virtual  file  system  per  hardware  port).  A  primary  reason  for 
having  multiple  virtual  file  hierarchies  is  to  avoid  the 
problem  of  naming  conficts  which  would  eventually  occur  in 
the  Supervisor  hierarchy  as  the  system  .grew  if  per-host 
virtual  file  systems  did  not  exist.  Multiple  directories 
also  allow  the  Host  systems  to  group  related  files  into  one 
directory,  simplifying  search  and  Eost  use.  The  Supervisor 
will  control  the  duplication  problem  within  a  virtual  file 
system  by  not  allowing  dvnlicate  file  names  in  a  single 
directory  file.  Pathnames  are  required  to  uniquely  identify 
files  in  the  Supervisor  file  systems  and  must  be  included  in 
the  Host  reauest . 

Access  to  the  Supervisor  file  hierarchy  is 
controlled  in  both  a  discretionary  and  non-discretionary 
mar.rer.  The  non-di scret icrary  access  is  controlled  by  the 
Kernel  which  will  prevent  a  Host  system  from  reading  up  or 
writing  down  (confinement  property).  Discretionary  access  to 
the  files  is  handled  by  the  Supervisor  which  compares  the 
Host. user  •'Host  use"  combination)  with  the  file  ACL. 
Reauestei  access  is  permitted  only  if  the  Host. user  is 
explicitly  permitted  access  by  the  file  ?.CL. 

Tach  Host  system  virtual  file  hierarchy  is 
constructed  from  data  files  and  directory  files  which,  as 
mentioned  above,  are  constructed  of  Supervisor  segments. 
Although  dynamic  growth  and  shrinkage  are  usual  segment 
attributes,  a  design  choice  for  System  simplification  was 
made  to  fix  segment  size  at   three   increments,   SM4LL   (512 
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bytes),  MEDIUM  (2K  bytes),  and  L*BGY  (SI  bytes).  These  sizes 
were  chosen  as  a  compromise  between  expected  file  sizes, 
Supervisor  buffer  retirements,  and  minimizins  the  number  of 
software  ring  crossings  that  would  be  required  during  a  data 
file  'read'  or  'store'  operation.  Pecause  se^^ent  size  is 
limited  and  there  exists  the  likelihood  of  encountering 
files  larger  than  the  maximum  segment  size,  the  concept  of  a 
multiple  segment  file  (msf)  is  known  to  the  Supervisor. 

Figure  5  denicts  the  general  tree  structure  of  a 
Supervisor  virtual  file  hierarchy.  Directory  files  are 
represented  by  sauares  and  data  files  by  circles.  Data 
files,  as  their  name  implies,  contain  data  only.  Directory 
files  are  constructed  of  a  header  and  zero  or  more 
"entries".  There  are  two  types  of  entries,  branch  entries 
and  link  en t ri es  . 

Pranch  entries  contain  the  attributes  of  the  file 
which  they  identify.  In  figure  5,  for  example,  the 
attributes  of  directory  file  User_l  'entry  r.ane,  fCL,  size, 
type,  etc.)  are  contained  in  directory  file  Hcst_l,  branch 
entry  User_l.  One  branch  entry  designates  one  Supervisor 
segmen  t . 

»  link  entry,  represented  by  the  dotted  line  ir 
figure  5.  is  composed  of  an  "entry  name"  (link  name)  and  a 
pathname.  ( «  pathname  is  the  concatenation  of  entry  names 
starting  from  the  root  directory  and  proceeding  in 
seouential  order  to  the  specified  file.)  Like  a  branch 
entry,  a  link  entry  is  used  to  access  a  specific   file.   For 
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example,  in  figure  5,  the  pathname  contained  in  the  link 
entry  is  Hos t_I>User_3>Lir_l .  Unlike  a  "branch  entry, 
however.  the  link  entry  does  not  contain  any  file 
attributes.  Access  is  controlled  as  tne  Supervisor  traverses 
the  specified  path  to  the  requested  file. 

The  use  of  link  entries  allows  sharing  of  files 
among  Host  systems  ana"  among  Host  system  users.  Loops  which 
might  be  venerated  by  two  links  which  reference  each  other, 
are  prevented  by  the  Supervisor.  (Loons  could  present  a  tree 
traversal  problem  to  the  Suoer visor.) 

Each  file  has  a  file  name  (Entry_\'are — uniaue  per 
directory  file)  .?iven  by  the  Host  system  at  file  creation 
time.  This  file  name  and  its  pathname  are  used  to  ur.iouely 
locate  the  file  in  the  Host's  virtual  file  system.  By 
traversing  the  virtual  hierarchy,  the  Supervisor  can  locate 
the  reauested  file  if  it  exists  in  the  system.  In  either 
case  (viz.,  whether  the  file  exists  or  not),  appropriate 
action  can  be  taken  by  the  Supervisor. 

a.   Directory  File 

Figure  6  is  e  logical  representation  of  a  file 
directory.  "Each  directory  file  is  made  up  of  a  heade7*  and 
zero  or  rrore  fixed  size  branch/link  entries.  A  fixed 
directory  size  of  LP :3G2  (8K  bytes)  was  chosen  to  insure  a 
reasonalble  amount  of  directory  space  for  Host  system  use. 
This  could  rose  a  "space"  problem,  especially  for  secondary 
storage.  (Adeauate  main  memory  can  be  installed  for  reauired 
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buffer  space.)  The  Kernel,  which  stores  segments  as  pages, 
lay  want  to  'compact'  segments  by  not  storing  or.  secondary 
storage  pases  which  contain  all  "zeros".  This  would,  greatly 
reduce  the  amount  of  wasted  space  on  secondary  storage. 
(Another  equally  viable  solution,  but  not  selected  for  this 
desisn,  is  to  have  multiple  segment  directories  in  the 
Supervisor  similar  to  multiple  segment  data  files.)  The 
directory  file  reader  contains  the  following  information: 

Entry_Count  :  This  is  the  number  of  branch/link 
entries  in  the  directory. 

ACL_Count:  This  is  a  count  of  the  number  of 
i.CL_I'N'TRY  elements  left  in  a  "pool"  of  such  elements. 

If   the  entry  is  a  branch  entry,  it  will  contain 

the  following  elements: 

T,ntry_^!ame:  Fntry  name  is  the  file  name.  The 
En?t  systems  a^e  responsible  for  supplying  these  names  but, 
as  mentioned  above,  will  be  prevented  by  the  Supevisor  from 
havin?  duplicate  names  (file  names)  in  ore  directory  file. 

Access_Class :  This  element  certains  the  file 
access  level . 

3ranch_Link_Switch :  This  element  will  identify 
the  entry  as  a  branch  ent^y  which  in  turn  specifies  the 
entry  format. 

ACL_Ptr:  This  element  will  poirt  to  ar  ACL  for 
the  branch  entry.  The  7SS  has  only  three  distinct 
discretionary  access  modes:  1)  "null"  access  as  the  name 
implies,   declares   that   no   access  is  to  be  allowed  to  the 
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specified  Host. user  combination,  2)  "read"  access  allows  a 
Qualified  Host. user  to  read  a  file  only  (i.e.,  no  write 
access),  3)  "write"  access  allows  a  Host. user  write  access 
to  a  file  (also  implicit  read  access).  The  actual  ACL  will 
be  a  list  cf  authorized  users  ir  the  form  Host. user  with  ar 
associated  access  mode.  A  'don't  care'  authorization  (in 
this  case  a  *) ,  will  allow  general  access  in  that  category. 
■^or  example,  *.user  would  allow  the  specified  'user'  to 
access  this  file  fro^  any  connected  Host  system  with  a 
specified  access  mode.  This  ACL  for  entry  "user"  can  easily 
be  expanded  to  include  other  categories  such  as  'pro/joct"  to 
further  refine  the  discretionary  access  allowed  to  a  file. 

File_Size:  This  information  is  nor-essary  for 
nroper  management  of  the  Host  HiAI_JILI  and  STCR1!_FILE 
commands  by  the  Supervisor,  viz..  it  allows  the  Supervise1" 
to  calculate  the  number  of  segments  that  ma.-ce  uo  a  multiple 
segment  file.  It  will  be  supplied  by  the  Host  system  in  the 
STCRS_FIL3  command  reouest  -in  bits). 

Data_Bir_Switcr ;  This  switch  tells  the 
Supervisor  the  type  of  file  to  which  the  branch  points 
'data,  directory).  This  is  necessary  due  to  the  different 
file  formats. 

?i le_Crea ted :  This  ele^ert  is  used  for  general 
audit  purposes,  i.e.,  to  have  a  permanent  record  cf  the  file 
creator  and  the  time  of  creatior. 

Last_Undater  This  element  will  identify  the  last 
Host   a^id  user   to  store  into  the  file.  This  identification 
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will  be  of  the  fori-  Hos  t  .usnr  .da  te.  time .  This  will  allow  the 
FSS  to  have  a  limited  audit  capability.  The  confinement 
property  prevents  the  FS5  frcn  also  keeping  track  of  read 
accesses  since  processes  at  higher  levels  can  read  at  lower- 
levels  hut  cannot  write  +he  audit  information,  ftlso  note, 
that  the  Last_Update  information  for  upgraded  directories 
nay  rot  he  accurate  for  the  sa-^p  reason. 

If  the  entry  is  a  link  entry,  it  contains  only 
four  elements.  These  are:  1)  Entry_:Mame  to  identify  the 
file,  2)  ?ranch_Link_Swi  tch  to  identify  the  entry  type,  3) 
Link,  a  pathname  to  uniquely  identify  a  file,  an.3  4) 
f,reate_Time ,  the  time  of  link  initiation  alon^  with  the 
Host. user  who  creafed  the  link.  All  attribute  checking  is 
done  as  the  Supervisor  traverses  the  specified  path. 

A  FSS  design  choice  is  to  limit  all  pathlengths 
to  125  bytes.  This  places  some  restrictions  on  the  "est  in 
that  lor,?;  file  names  will  soon  consume  the  bytes  available 
for  a  pathname.  rDwever,  this  restriction  can  be  overcome  by 
pathnames  which  contain  several  link  entries,  which  can 
themselves  be  128  bytes,  '.v'ith  32  branch/link  entries  per 
directory,  there  are  an  average  of  32  ACL  entries  (3  bytes 
each)  available  to  each  branch  entry.  ( Remember ,lirk  entries 
do  not  have  ACL  entries.)  Figure  5  contains  the  initial 
field  sizes  for  the  directory  construction.  The  primary 
factor  in  calculating  the  size  of  branch/link  entries  is  the 
size  of  the  link  pathname.  This  increasec  the  size  of  link 
entries  to  163  bytes  and  althoush  snace  is  wasteo  in   branch 
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entries,  the  simplif icat ior.  of  System  design  resulting  f r om 
a  fixed  size  of  branch/link  er.try  is  felt  to  be  sufficient 
justification  in  the  initial  design. 

t.   Tata  viles 

Data   files   are  always  "leaf"  nodes  in  the  file 
hierarchy  ar.d  contain  only  data. 


c.   Multiple  Segment  File  Directory 

A  msf  directory  is  a  Supervisor  construct 
(invisible  to  Host  systems')  to  manage  files  larger  than  the 
maximum,  fixed  segment  size.  Because  the  number  jf  segments 
that  will  he  reauired  by  the  Supervisor  to  store  a  file  car- 
te calculated  from  the  file  size  information  passed  by  the 
Host,  a  msf  directory  need  orly  be  a  segment  of  size  zero. 
This  makes  the  Kernel  alias  table  (which  is  a  fixed 
size — see  [Colemanl )  the  limiting  factor  in  the  maximum  file 
size.  The  alias  table  has  the  same  number  of  entries  as  a 
Supervisor  directory  (viz.,  32)  which  limits  maximum  Host 
file  size  to  256K  bytes.  Tiles  that  exceed  the  ma^i-num  file 
size  must  be  split  by  the  Host  system.  ,Sti  attempt  tn  store  a 
file  that  is  'too'  large  will  result  is  an  error  condition 
response  to  the  Host  and  an  unexecuted  command. 

4 .   Host  System  Commands 

The   Host  commands  Drovide  the  only  interface  that  a 
Host  system  has  with  the  TSS.  Each  command  is  interpreted  by 
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the  FS3  and  acted  upon  by  surrogate  Supervisor  processes? 
the  uost  system  has  no  direct  access  to  the  FSS.  There  is 
one  acknowledgement  "between  the  Host  and  735  at  this  level. 
This  is  a  "command  complete"  acknowledgement  that  informs 
the  Eost  system  that  the  Supervisor  has  completed  action  on 
its  reauest.  If  an  error  condition  occurs,  the  appropriate 
error  cede  is  returned  in  the  acknowledgement. 

Another  aspect  of  the  Host  environment  needs  to  be 
defined  also.  The  Host  environment  can  be  divided  into  two 
states?  they  are  the  "oil"  state,  before  the  FSS  has  acted 
upon  the  Host  reauest,  and  the  "new"  state,  which  occurs 
after  action  has  been  completed  by  the  FSS.  The  specific 
sta+e  of  the  FSS  at  any  instant  is  indeterminate  at  the  Host 
level  if  more  than  one  nost  is  accessing  the  same  file  of 
the  FSS  at  o^e  tine.  That  is,  since  Supervisor  processes 
execute  in  a  completely  asynchronous  manner,  the  TSS  state 
may  change  after  a  Host  command  is  sent  but  before  the  FSS 
acts  en  tne  command.  This  will  not  affect  the  oerformence  of 
the  System  or  validity  of  its  security?  Host  commands  will 
be  executed  as  a  single,  atomic  operation  in  the  FSS  state 
in  which  they  are  received  and  interpreted.  The  Host  will 
get  some  "correct"  response  for  some  state  existing  between 
the  sending  of  the  Host  command  and  the  FSS  acitr  owledgemer  t 
on  the  same  command.  This  allows  several  Hosts  to  safely 
synchronize  their  actions  external  to  the  FSS. 

The  follrwir.fr  is  considered  to  be  a  minimal  subset 
of  commands  available  to  the  Host  System  for  adecuate   file 
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control.  Figure  7  illustrates  the  reauired  discretionary 
access  attributes.  T^e  files  are  referenced  in  the  Host 
Command  descriptions  starting  from  the  root  of  the  Hcst 
virtual  file  system.  The  pathname  specifies  the  parent 
directory  file  (containing  access  attributes  of  the  file), 
and  the  file  (data  or  directory)  to  which  the  ucst  command 
refers.  All  commands  reriuire  a  pathname  for  ur.iaue  file 
identification.  Fach  command  also  reauires  tne  specification 
of  the  Host  system  "user"  in  order  for  the  Supervisor  to 
nerform  discretionary  security  checks.  This  'userid"  will  be 
supplied  by  the  Host  system  or  the  Host,  system  user,  which 
ever  is  appropriate. 

CR2ATE_FILE  <pathname,  access_class ,  file_type 
'directory,  data)>.  This  command  reauests  that  the 
Supervisor  create  a  branch  entry  in  the  specified  directory 
under  the  specified  file  name  at  the  specified  access  class. 
Ar  initial  access  mode  of  write  will  be  .fiven  to  file 
creator  and  nnay  be  altered  by  the  use  of  the  £DD_ACL_ENTRY 
and  DELETE_ACl_ENTRY  commands.  This  is  the  only  Host  cormand 
where  file  access  class  is  specified.  It  is  used  ir.  this 
command  to  create  upgraded  directory  files,  if  desired. 
(Data  files  may  not  be  ungraded — described  later.)  In  the 
initial  implementation  (with  single  level  Hosts),  there  will 
be  no  ungraded  directories  within  a  Host  virtual  file 
system.  Initial  data  file  size  is  zero?  initial  directory 
file  size  is  LARTF  (s=k  bytes).  Actions  taken: 

1)  The  Supervisor  locates  the  root   of   the   virtual 
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file   system   for   this   Host   arl   does  a  tree  traversal  to 
locate  the  parent  directory  file. 

2)  If  the  parent  directory  file  is  not  found  or 
found  but  write  access  to  the  parent  directory  file  is  not 
allowed,  ar  appropriate  error  code  is  returned  ''"file  not 
found'  or  'write  rot  permitted'^. 

3)  If  the  directory  file  is  found,  and  room  exists 
in  the  directory,  the  new  file  is  entered  in  a  t^-anch.  As 
mentioned  above,  re  duplicate  file  names  will  be  allowed  by 
the  Supervisor. 

CRSAr'?_LIKJK  ^pathname,  link  ,userid>.  This  command 
reauests  that  the  Supervisor  create  a  link  in  the  specified 
directory  under  the  specified  file  name.  As  already 
mentioned,  the  Supervisor  will  not  allow  links  to  form 
loops.  This  is  done  by  restricting  the  maximum  number  of 
files  in  one  pathname  to  64  files.  (This  figure  is  reached 
by  allowing  a  maximum  pathlength  of  122  bytes  and  having 
file  names  of  ore  character.  File  name  delimiters  of  one 
character,  viz.  ">",  will  £ive  a  maximum  pathlensth  of  64 
files.)  3y  keepir..?  track  of  the  path  traversed,  the 
Supervisor  is  able  to  determine  if  and  when  a  loop  is 
formed.  Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tnee  traversal  to 
locate  the  parent  directory  file. 

2)  If  the  parent  directory  file  is  not  found  or 
found  but  write  access  to  the  parent  directory  file   is   not 
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allowed,  an  appropriate  error  code  is  returned. 

3)  If  the  parent  directory  file  is  foun.d  and  room 
exists  in  the  directory,  the  link  is  entered  in  a  link 
entry . 

DELETS_FILF  Pathname  ,userid>.  This  command 
reauests  that  the  Supervisor  delete  the  specified  file  from 
the  virtual  file  hierarchy,  ^or  design  simplicity,  only 
terminal  files  (including  msf's),  can  he  deleted.  This  meais 
that  directories  must  be  empty  in  order  to  he  deleted. 
Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  parent  directory  file. 

2)  If  parent  directory  file  is  not  found  or  found 
hut  write  access  to  the  parent  directory  file  is  not 
permitted,  an  acuropriate  error  code  is  returned. 

3)  Otherwise,  if  the  file  is  located,  it  is  ?ele+ei 
oy   the  Supervisor. 

READ_FILE  ^pathname,  command_ type ^direct o ry,  data, 
size)  ,userid>.  This  command  reauests  that  the  Supervisor 
transmit  to  the  Host  either  a  data  file,  directory  file 
^selected  elements  only),  or  the  File_Size,  Last_Update,  and 
Access_Class  ''entry  data)  elements  associated  with  a 
particular  file.  ?n  explanation  of  the  last  parameter,  to 
transmit  e^try  data  only,  reeds  s^me  explanation. 

"Branch   entry  elements  can  be  logically  divided  into 


two  categories  with  respect  to  discretionary  security.  The 
first  category,  which  includes  Tntry_Name, 
Branch_Lin>_Svitch,  Access_Class ,  a^d  ACL_?tr  are  branch 
entry  attributes  which  cannot  be  altered  by  a  Host  process 
unless  the  process  has  discretionary  write  access  to  the 
directory  which  contains  the  file  branch  entry. 

The  second  category,  which  contains  File_5ize  and 
Last_Update,  are  attributes  which  'belong  '  to  the  file  and 
must  be  updated  when  the  file  is  updated.  A  situation  nay 
exist  where  a  uroces?  may  not  have  any  discretionary  access 
to  a  directory  but  may  have  discretionary  read  access  to  a 
file  in  the  directory  (nlus  implicit  access  to  the  rest  of 
the  directory  during  the  "search").  In  order  to  read  this 
file,  the  Host  system  will  need  to  know  file  size  in  order 
to  prepare  to  receive  it.  This  is  the  situation  where  the 
?.?SD_?IL1T  (size)  command  is  needed.  flctions  taken:  (for  data 
file) 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  ani  does  a  tree  traversal  to 
locate  the  desired  directory  file. 

2)  If  the  file  is  not  found  or  found  but  read  access 
to  the  file  is  not  allowed,  an  appropriate  error  message  is 
returned . 

^)  Otherwise,  the  file  is  transmitted  to  the 
reouesting  Host  System. 

''for  directory  file1* 
1)  Same. 
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2)  Same. 

31!  If  the  directory  file  is  found  and  read  access 
allowed,  selected  elements  of  the  branch/lins  entries  are 
returned  to  the  Host. 

'for  file  size) 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  to 
locate  the  desired  file. 

2)  If  the  file  is  not  found  or  found  but  read  access 
to  the  file  is  not  permitted,  an  appropriate  error  cede  is 
returned . 

3)  Otherwise,  the  File_Si->e  and  Last_Update  elements 
are  returned  to  the  Host. 

STCR"5_?ILE  <pathname,  file_size  ,userii>.  This 
command  reauests  that  the  supervisor  store  the  sperified 
file  in  the  HSS.  Actions  taken: 

1)  The  Supervisor  locates  the  root  of  the  virtual 
file  system  for  this  Host  and  does  a  tree  traversal  tc 
locate  the  data  file. 

2)  If  the  data  file  is  not  found  or  found  cut  write 
access  to  the  data  file  not.  allowed,  an  appropriate  error 
code  is  returned.  Note  that  Host  systems  can  store  only  data 
files;  directories  are  'built'  by  the  Supervisor. 

3)  Otherwise,  a  store  operation  is  performed  by  the 
FSS. 

READ  ACL  ^pathname  ,userid>.  This  command  is  used  by 
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the  Host  systems  in  conjunction  with  the  ADD_S,CL_ENTF.Y  and 
P'PITT'?_ACL_ENTHY  to  adjust  (give/rescind)  the  access  mode 
(read /write)  allowed  to  a  Host /Host  user  to  a  specific  file. 
Actions  taken: 

1)  The  Supervisor  locates  the  the  root  cf  the 
virtual  file  system  for  this  Post  and  does  a  tree  traversal 
to  locate  the  parent  directory  file. 

2)  If  the  file  is  rot  found  or  is  found  tut  read 
access  is  net  allowed  to  the  parent  directory  file,  an 
appropriate  error  code  is  returned. 

3)  Otherwise,  the  supervisor  returns  the  file  ACL 
for  Host  system  user  examination. 

ADD_ACl_ENTRY  ^ pathname,  ACL_Er.try  ,useridN-.  This 
command  reauests  the  Supervisor  to  add  to  the  specified  file 
ACL  the  specified  1CL_'Entry  (Host. user  conbir.a  tior  plus 
associated  access  mode).  as  with  the  orevious  commands,  the 
access  is  checked  for  correctness  hy  both  the  Supervisor  and 
the  Kernel  before  any  action  is  taken. 

DELETE_ACL_ENTRY  ^pathname,  5CL_2ntry  ,userid>.  This 
command  reauests  that  an  ACL_Er;try  he  deleted  from  a  file 
ACL.  A^ain,  appropriate  discretionary  and  non-discretionary 
checks  are  made  before  any  action  is  taken  by  the  FSS. 

APOF.T.  This  command  reauests  the  Supervisor  to  quit 
execution  of  the  present  conmard  ari  return  the  file  system 
to  its  original  state.  There  are  only  certain  locations  in 
the   execution   of  Host  commands  that  the  Supervisor  is  able 
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to  interupt.  If  an  4B0F.T  command  is  received  after  an 
operation  has  teen  completed  but  before  the  final  Host 
acknowledgement  is  sent,  the  original  command  completion 
will  be  acknowledged  and  the  abort  command  will  be  ignored. 
Otherwise,  action  of  the  command  will  be  halted  a^d  the 
Supervisor  will  wait  for  another  Host  command.  All  Host 
commands  (including  &BOB.T)  will  be  explicitly  acknowledged 
with  either  a  "command  complete"  message  or  an  appropriate 
error  code. 

C.   PROCESS  STRUCTURE 

There  are  two  Supervisor  processes  which  act  on  behalf 
of  each  Host  system  (hardware  port).  The  inpnt/cutput  (10) 
process  and  the  file  manaee-nent  (FM)  process.  The  10  process 
is  responsible  for  communication  and  data  transfer  (via 
packets)  between  the  Supervisor  and  the  Host  system.  The  FM 
process  is  responsible  for  managing  the  per-Host  virtual 
file  systems  and  providing  overall  FSS  control.  &.11  Host 
commands  are  interpreted  by  the  FM  process!  the  10  process 
acts  in  a  "slave"  mode  to  the  TM  process.  Acting  together, 
the  FM  and  10  processes  interpret  and  execute  the  file 
management  reauests  of  the  Eost  systems.  Kernel  primitives 
HEAD,  »D7ANCE,  AWAIT,  and  TICKET  used  in  conjunction  with 
eventcounts  and  seauencer  (described  later),  are  used  to 
synchronize  Host  surrogate  -process  execution. 

Both  the  FM  and  10  processes  call  on  Kernel  primitives 
to   perform  actual  seamert  manipulation.  The  normal  order  in 
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which  these  calls  are  made  is  fixed  by  the  Kernel  design.  To 
add  a  segment  to  a  process  memory,  the  order  of  kernel  calls 
is:  1)  C-ate^eeper .  r'reate_Sesment ,  2)  Gatekeeper. MakeJEaown, 
aM  ?)  Gatekeeper  .Swap_Ir. .  To  delete  a  segment  from  a 
urocess  memory,  the  order  of  Kernel  calls  is:  1) 
gatekeeper.  Swap_0ut ,  2)  Gatekeeper .Terminate ,  ar.d  3) 
Gatekeeper. Delete_Se,?ment .  The  Supervisor  procedures  use 
these  invokation  orders. 


There  are   three   levels 


abstraction   for   a   Host 


surrogate  process.  They  are:  1)  the  level  at  which  Host 
commands  are  known.  2)  the  level  at  which  files  are  known, 
ard  3^  the  level  at  which  Supervisor  segments  or  packets  are 
,-cnown.  These  levels  of  abstraction  should  be  kept  in  mind 
when  readies  the  Fr1  and  10  process  descriptions. 

A  design  choice  to  simplify  file  system  maintenance  and 
control  is  to  all^v  upgrading  of  or.ly  directories  (e.t-., 
unclassified  to  secret).  This  will  eliminate  the  possibility 
of  having  a  secret  file  in  an  unclassified  iirectorv,  a 
situation  which  would  prevent  up latins  of  the  file  branch 
data  by  the  secret  process  siroe  writing  "down"  is  rot 
allowed.  This  restriction  is  not  felt  to  exclude  any 
significant  FSS  capabilities  and  provides  for  a  simplified 
implementation . 

The  modular  construction  of  the  FSS  enhances  System 
structure.  All  data  bases,  except  the  files  themselves,  are 
module  local.  Codp  is  expected  to  be  written  in  PLZ/STS 
[Snook],   which   is   a   hish   level   uascal-like   structured 
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iroaramming  language.  Pecause  of  the  its  length,  code  is 
^Located  in  Appendix  C.  The  code  listed  in  this  appendix 
aives  the  interprocess  and  intermodule  control  structure  of 
the  FSS. 

1.   Shared  Segment  Interactions 


Supervisor  nrocess  execution  occurs  in  a  completely 

asynchronous  manner.  When  a  process  is   refered   to   in   the 

*  following  discussions,  the  two  Host  surrogate  processes  are 

being  referenced;  these  surrogate  processes  have   the   same 

clearance  levels  as  the  Host  they  represent. 

As  already  mentioned,  the  task  of  the  FSS  is  to 
provide  a  service.  To  he  of  maximum  benefit,  this  service 
should  be  unambiguous,  easy  to  use,  and  robust. 

The  major  problem  that  the  FSS  must  handle  for 
proper  System  security  is  the  confinement  problem,  viz.,  to 
prevent  a  process  from  reading  a  file  with  a  hi=?ver 
classification  or  writing  ;i.e.,  storing  or  updating)  a  file 
with  a  lower  classification.  This  .icb  is  handled  entirely  by 
the  Kernel. 

Another  problem  closely  related  to  the  confinement 
problem  which  also  ir.voles  the  Supervisor,  is  the 
readers/writers"  problem  [Courtoisl.  Ir>  order  to  preserve 
file  inte^rety,  reading  and  writing  of  e  shared  file  cannot 
be  allowed  at  the  same  time.  Since  a  primary  objective  of 
the  PSS  is  to  provide  for  the  sharing  of  files,  this  problem 
will  certainly  occur  and  must  be  handled  properly  for  System 


viability. 

Both  the  confinement  problem  and  the  readers/writers 
■problem  can  be  solved  in  one  of  two  ways.  Mutual  exclusion, 
a  mechanise  which  forces  a  tire  ordering  on  the  execution  of 
critical  regions,  forces  concurrent  processes  into  a  total 
order  execution  sequence.  This  is  counterproductive  to  the 
purpose  of  a  process  structure,  which  inherently  allows 
concurrent  execution  of  processes. 

A  second  and  relatively  new  method  is  the  use  of 
eventccurts  and  sequencer  [Reed]  to  control  access  to 
critical  regions.  This  method  preserves  the  idea  of 
concurrent  processing  to  a  ruch  greater  extent.  Ap 
eventcount  is  a  object  that  keeps  count  of  the  number  of 
events  (in  the  case  of  the  FSS,  segment  read/writQ  accessps) 
that  have  occured  so  far  in  the  execution  of  the  System 
procedures.  These  eventcounts  are  associated  with  the 
Supervisor  se?Tent5.  They  are  accessed  only  via  Kernel  calls 
a^d  can  be  thought  of  as  non-decreasing  integer  values.  Each 
Supervisor  segment  has  two  eventcount s  associated  with  it, 
one  to  keep  track  of  the  read  accesses  aid  one  to  keep  track 
of  the  write  accesses. 

A  Kernel  urimitive  ADVANCE  signals  the  occurrence  of 
an  event  (read/write  segment  access)  associated  with  a 
particular  segment  eventcount.  The  value  of  an  eventcount  is 
the  number  of  ADVICE  operations  that  have  been  -oerfomed  on 
it.  A  process  can  observe  the  value  of  an  eventcount  by 
either   n!EAD''Seg_#,  E),  which  returns  the  value  directly,  or 
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by  ?.WA  IT  '  Seg_# ,  T,  t),  which  returns  when  the  eventcount 
reaches  the  specific  value  t. 

8  sequencer  is  also  necessary  to  solve  the 
Conf  inerrent  and  readers/writers  problems.  Sore 
synchronization  Droble^s  reauire  arbitration  'e.g.,  two 
write  accesses  to  the  sape  segment)?  eve" tcounts  al^ne  do 
not  have  the  ability  to  discrininate  between  two  events  that 
happen  in  an  uncontrolled  'i.e.,  concurrent  J  manner.  A 
seauencer,  like  eventcounts,  can  be  t^ou^ht  of  as  a 
non-decreasing  integer  variable  that  is  initially  zero.  Each 
Supervisor  segment  has  associated  with  it  one  sequencer.  The 
only  operation  on  a  seauencer  is  a  Kernel  primitive 
operation  called  TICKET fSeg_#,  S),  which,  when  applied  to  a 
sequencer,  returns  a  non-negative  integer  value.  (Similar  to 
getting  a  ticket  and  waiting  to  be  served  at  a  ba-ber  shop.) 
Two  uses  of  TICK^Tf Seg_*.S )  will  return  two  different  values 
corresponding  to  the  relative  'time"  of  call. 

The  segne'-t  number  associated  with  these 
synchronization  primitives  informs  the  Kernel  of  which 
segment  is  being  referenced.  The  use  nf  eventcounts  and 
seauencer  can  he  illustrated  by  examining  the  following  two 
urocedures  fread  O  as  not  equal).  The  FSS  implements  these 
functions  in  the  Direct ory_Control  module  located  in  the  FM 
nrocess . 
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PROCEDURE  reader 

PEGIN  INTEGER  w? 
abort:   w  :=  READ(Seg_#,S ) >  'get  reader  eventcount! 

AWAIT(Seg_#,c7w) J  !wait  until  write  corrplete! 
'read  file  '; 

if  READ(Se«_#,S)  <>  w  THEN  GOTO  abcrtlread  again 
END 


PROCEDURE  writer 
"BEGIN  INTEGER  ti 

ADV?NCE(Seg  tf,S);  lincrement  reader  eventcount! 

t  !=  TICKETTSeg_*,T);  Iget  seauencer! 

AWAIT(Seg_*,C,  t")i  !wait  for  write  to  complete! 

'read  and  update  file'; 

»DV *NCF(Seg  #, C) J  lincrement  writer  eventcount! 
END 


The  Kernel  will  enforce  the  confinement  property  and 
prever*  the  application  of  the  ADVANCE  and  TICKET  primitives 
to  segments  with  an  access  class  less  than  the  Host  access 
class.  Mot  to  in  so,  would  allow  a  communication  path  to  he 
created  cetwee71  two  different  access  levels.  The  two 
eventcounts  a  Supervisor  sermert,  will  have  associate^  wir.h 
it  (in  the  ^ernel^  are  a  write  eventcount,  C,  and  a  read 
eventcount,  S.  Each  segment  will  also  have  a  seauencer,  T, 
associated  with  it.  Eventcounts  and  seauencer  are  initially 
zero. 

These  eventcounts  and  seauencers,  with  their 
associated  Kernel  primitives,  are  used  by  the  ESS  to  oerform 
the  synchronization  functions  of  "^locV:  and  Wake  up  ("Coleman!  , 
described  in  the  original  Kernel  design.  Eventcourts  and 
seauencers  provide  a  clearer  picture  of  the  process 
interaction  as  well  as  explicit  control  of  the 
readers /wri ters  '   problem.   Even   more   importantly,    they 
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permit  the  synchronization  between  processes  of  different 
access  levels.  This  is  essertial  in  ^rder  t<">  permit  a  hi^h 
level  Host  to  read  files  of  a  lower  level. 

Th°re  are  two  groups  of  Host  rpauests.  They  can  be 
classified  as  read  reauests  (e.s.,  ?:EA.I5_VI1E,  ??.S.D_ACL)  and 
write  requests  (e.g.,  CREATE_FILE,  ST0RE_FIL3).  These 
categories  can  he  further  subdivided  into  read  data  file, 
read  directory  file  and  write  data  file,  write  directory 
file  subcategories,  ^ach  category  tyoe  must  be  handled  in  a 
Droper  manner  by  the  Supervisor  to  insure  file  integrity, 
"ach  category  will  be  discussed  in  turn  beginning  with   the 

read  file  category. 

There   two  conditions  which  might  develop  over  which 

a  process  has  r\r  control"  file  update  by  another  process, 
and  file  deletion  by  another  process.  an  example  of  file 
update  might  occur  while  a  secre*  pt-oc°ss  is  traversing  a 
file  hierarchy  and  is  in  the  middle  of  search-ins  the 
directory  for  a"  Ent^y_Namc'  when  another  process  (at  the 
directory  access  level")  updates  the  directory.  Since  the 
secret  process  will  READ  the  segment  "reader"  eventcount,  S, 
before  and  after  the  search,  it  will  know  that  the  data  it 
had  obtained  is  possibly  invalid.  Although  there  does  rot 
aDpear  to  be  a  problem  with  allowing  the  'reaiin?'  process 
j&n  re-read  the  directory  file  until  a  "good"  read  is 
achieved,  a  closer  examination  of  this  condition  should  be 
made  at  implementation  time,  viz.,  is  it  possible  for  a 
'writing'  nrocess  to  alter   the   pathname   of  a   'reading' 


process   so   that   an  inconsistant  state  is  achieved  for  tha 
reading  process?  a  possible  solution  could  reouire  a  process 
which  suffers  a  "had"  read   to   begin   the   traversal   over,  ! 
beginning  at  the  root  directory. 

When  a  directory  is  being  read  to  pass  directory 
data  back  to  a  Eost,  the  directory  data  is  nut  in  a  buffer 
and  sent  from  there. 

?.  single  segment  buffer  nay  bp  to  s^all  to  hold  a 
data  file  'e.g.,  maximum  file  size  of  256K  bytes). 
Therefore,  to  present  the  Host  with  only  ^alid  data,  a  data 
file  "buffer"  is  needed  at  the  process  level.  Since  this 
buffer  will  be  at  the  process  access  level,  it  can  be  locked 
by  the  process  to  insure  that  no  other  process  interfers 
during  the  reading  operation  or.ce  the  data  file  is  ir  the 
buffer  file.  This  copying  of  the  data  file  is  lone  by  the  FM 
process  and  the  10  process  will  read  t^e  file  from  the 
buffer  file  when  transfering  the  file  to  a  Host  system.  The 
choice  of  Taking  a  cory  of  a  data  file  is  awkward  but 
considered  necessary  in  order  to  provide  the  Host  with  only 
atomic  operations,  i.e.,  to  prevent  the  situation  fro^ 
occuring  where  half  of  a  ten  segment  msf  is  transmitted  to 
the  Host  and  the  file  is  either  updated  or  deleted. 

The  other  condition  which  may  arise  during  a  file 
read  is  a  file  deletion.  This  situation  occurs  when  one 
process  is  reading  a  file  and  another  process  deletes  the 
sa^e  file.  The  first  procpss,  rot  knowing  that  the  file 
| segment)   has   been  deleted,  will  try  to  reference  the  file 


again.  A  hardware  segment  fault  will  occur  and  cause  a 
transfer  of  control  to  the  Kernel.  Note  that  in  this 
situation,  it  is  the  higher  access  class  process  which  will 
suffer  the  fault  while  it  is  reading  a  lower  scress  class 
file.  To  handle  this  problem,  viz.,  the  Supervisor  segment 
fault,  a  fault  handler  must  he  part  of  the  distributed 
Supervisor.  A  Kernel  primitive  also  ree^s  defirirg.  This 
primitive,  Gatekeeper. On_?ault  (?ault_cor.dition,  Sntry_pt), 
is  called  in  the  initialization  of  the  Supervisor  process 
where  it  is  possible  for  a  segment  fault  to  occur.  A  call  to 
a  Superivsor  condition  establisher  is  also  necessary.  This 
will  nlace  a  specific  condition  handler  on  a  'condition 
stack:".  If  a  fault  occurs,  the  Kernel  returns  to  the 
Supervisor  fault  handle^  with  a  'segment  fault'  error 
condition.  This  fault  handler  in  turn  transfers  control  to 
the  condition  handler  at  the  top  of  the  'condition  stack' 
which  can  nake  a  normal  return  from  all  procedures,  '.'/hen  the 
error  condition  is  detected  ''from  the  return  code)  by  the 
appropriate  Supervisor  level,  action  is  taken,  viz.,  the 
Host  command  in  re-initiated.  Sirce  the  file  ( segment ( s) ) 
has  been  deleted,  this  reinvocation  may  well  rasult  in  a 
'segment  not  found'  error  condition  being  returned  from  the 
Kernel  and  a  "file  not  found"  error  condition  being  relayed 
to  the  Host.  When  the  Supervisor  e^its  the  "sesment  fault"  a 
''revert"  command  is  necessary  to  remove  the  condition 
handler  from  the  condition  stack. 

Another  side  benefit  of  bavins  the  Supervisor  do  all 
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the  actual  file  reading  (ard  therefore  take  all  the  segment 
faults)  is  that  it  prevents  a  hardware  fault  from  occuring 
during  the  actual  data  transfer  in  the  Kernel  during  10 
process  execution?  this  condition  would  force  the  handling 
of  the  fault  in  the  Kernel  domain — a  difficult  tas^. 

Writing  a  file  is  a  more  straight  fore w ari  task:  ard 
presents  fewer  problems.  This  is  because  a  writing  process 
has  the  sane  access  class  as  the  file  ard  car  prever1"  all 
other  access  to  the  file  (segment! s) )  it  is  concerned  with. 
To  alter  a  directory  ( C?.EATT_FIL2,  DFL2TE_FIL2 .  etc.),  a 
orocess  will  <?et  a  ticket  to  the  directory  and  perform  the 
necessary  manipulation  when  its  number  is  called.  In  ^rder 
to  store  a  file,  more  care  must  "be  taken.  If  a  process  were 
allowed  to  store  directly  into  the  old  file,  the  possibility 
exists  that  a  software  or  hardware  error  might  result  in  a 
partially  updated  file  and  loss  of  file  integrity.  To 
prevent  this  from  occurring,  a  data  file  is  first  store! 
ir.tc  a  temporary  ^ile  set  up  by  the  FM  process.  This  also 
,  allows  the  original  file  to  continue  to  te  read  by  otner 
processes  while  the  store  operation  is  g^ing  en,  a 
significant  advantage  if  the  data  file  is  long.  *fter  the 
file  is  stored  by  the  10  process,  the  FM  process  gets  a 
ticket  to  the  file  directory  and  when  its  turn  comes,  makes 
the  necessary  directory  updates,  viz.,  the  temporary  file 
name  is  subsituted  for  the  old  file  7ntry_\'ame,  Last_'Jpdate 
information  charred,  and  the  old  file  deleted.  (If  the  file 
is  a  msf,  each  segment  is,  of  course,  deleted.) 
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2.   File  Ma^a^ement  Process 

The  T":  process  is  composed  of  the  five  modules 
depicted  is  figure.  5  .(with  associated  Kernel  calls).  The  FM 
■process  is  the  controller  of  the  FSS  and  directs  all 
interaction  between  the  FSS  an-d  a  Host  system.  Each  nodule 
which  makes  up  this  process  will  be  described  alon<?  with  the 
procedures  which  Hake  up  the  individual  modules. 

a.   File  Management  Command  Handler  Module 


ks   depicted  i^.  figure  3,  the 


tr 


Command  Handler 


module  see  Appendix  C,  p.  134)  is  at  the  top  of  the  FM 
process  hierarchy.  This  is  the  level  of  abstraction  at  which 
Host  commands  are  "known".  This  module  is  responsible  for 
interprocess  communication  and  synchronization  (with  the  10 
process)  and  Host  command  interpretation.  Interprocess 
communication  is  achieved  by  the  Kernel  primitives  TICKET, 
ADVANCE  and  AWAIT  which  act  en  an  eventcount  associated  with 
the  shared  mail_box  ses-^e^t.  1?i?i;re  9  shows  the  logical 
construction  ard  +h°  da'a  base  description  of  the  mail_bcx. 
"^i^ure  l*  is  a  list  of  the  procedures  contained  within  the 
EM_Command_Handler  module  and  their  input  and  output 
parameters. 

The  FM_Cmd_Hnd  procedure  is  the  entry  procedure 
irto  the  FM_Command_Eandler  module.  This  is  toe  control 
procedure  of  the  module  and  is  responsible  for  routing  Host 
commands  to  specific  EM_Command_Har.dler  procedures  for 
action,  '."'hen  notified  by   the   10   process   that   a   command 


57 


Vail  Box 


FM  Command._Hand.ler 

Module 


Init iali zation 


£ 

N 

Gat  eke 

eper . 

Gatekeeper . 

On_Fault 

Ticket 

5a  tekeeper . 

Ai  ■"•ar  ce 
Gatekeeper . 

a  wait 

V- 

^ 

A 

S  e  £ rri  e  ^  t  K  a r'  d  1  °  r 
Module 


Gatekeeper , 
Make_KncwT 

Gatekeeper 
Terminate 


MeTry_Hardl er 
Module 


Gateke 

epe r  . 

Swap 

In 

Gatekeeper  . 

Swap_ 

Cut 

Di  re?tory_Cort rol 
vodule 


Ga  t  a'.reepe  r 

?ead 
Ga  tekeeper , 

Advance 

Gatekeeper 

>wa  it 
Gatekeeper. 

Ticket 


~*~ 


Discretionary 

Security  Module 


Gatekeeper . 

Create_5egmen t 
Gatekeeper . 

Eelete  Seiner. t 


Figure  ?. 


Process  Modules 


53 


Mail   3^r   Record    [ 


Command    Buffer 


Mr   Tata   Buffer 


»CL  Buffer 


Msg  3uffer 


Mail  Sot  Ses^er. t 


nommanii  Buffer 
n  *•  3ufFer 
ACL~Buffer 

Ms^  Buffer 


'may      [*  bytes] 
Array      [Max_Entryl      Dir_Bata 
■irray      [Max24CL_5i7e]    ACL_±ntry 
Record    [Inst  byte 

Pathname  string 

File_size  lword 

Success    cole    tyte] 


Figure   9.      Mail    Box   Segment 


59 


ptOCFDURF  INPUT 

FM   Cmd    End        P>st    Cmd 


FM_Cmd_  Pathname 

Delete_File  Userid 

FM_Cmd_  Pathname 

Create_File   File_Type 
Use  rid 


OUTPUT 

Mail_3ox. Msg. Inst 

Mai  l_3ox.Msg.Succ. Code 

Mail_3ox.Msg.Inst 

Mail_3ox.Msg.Succ_Code 

Mail_Box.Msg.Inst 
Mail    3ox.Msg.Succ   Code 


FM_Cmd_  Pa  +  hiar^e 

Create_Iirk  Link 

Userid 


Mail    Box. Ms*. Inst 

Kail    3ox.Mss.Succ    Code 


FM_Cmd_  Pathname 

Read_Fil^        Tile_Type 
Userid 

TM_CTid_      Pathname 
StTe_File   Fil°_Size 
Userid 

FM_f!md_      Pathname 
Read  Id,  Userid 


Mail  Box. Msg. Inst 
Mail^Pox  .Msg. Sue c_C ode 

Mail_Bn-.Msr:.?ile_Size 

Mailbox  .Msg.  Inst 
Mail_Box.Msg.Succ_Code 

Mail_B^x.Ms^.File_Si/re 

Mail_B0x.M5g.Inst 
Mail  Box .Msg. Sue c_C ode 
Mail  vox  .Msg. File  Size 


FM_Cnd_ 
Md_*CL 
Entry 


Path^a^0 
s  f!  t  f  n  t  r  y 
Userid 


FM_Cmd_      Pathname 
Delete_ACL_  ACL_Fntry 
E n  t ;  r y      Userid 


Mail_3^x .Msg. Ins  t 
Mail  ^ox.^Sft .Succ  Code 


Mail_3ox .Msg. Inst 
Mail  ^ox.Msa;.  Succ  Code 


Figure   10.      Comnand_Handler   Module 
Procedure    Input /Output    parameters 


60 


packet  is  ir  the  mail_box,  the  FM  process  retrieves  the 
command  and  begins  appropriate  action.  The  "est  command 
le.s.,  STORE_FILE,  XEAr_FILF)  is  actually  an  entry  into  a 
case  statement  which  directs  the  correct  FM_Comrnand_T-iandler 
procedure  to  fake  action.  Each  Host  command  has  associated 
with  it,  at  this  level,  its  own  procedure. 

Because  the  procedures  of  the  nodule  are 
relatively  straight  forward,  they  will  not  he  discussed  ir. 
detail,  "he  ^e^eral  functions  of  all  the  procedures  ir  this 
•nodule  are  to  pass  instructions  to  the  10  process  and  to  the 
Direct oT,y_Cor,tT'^i  module,  the  workhorse   of  the  FM  process. 

Some  explanation  of  Host  command  ua^ameters  is 
i r  order,  however.  These  parameters  (described  below)  are: 

pathname 

link 

file  type 

command  type 

file  size 

access  1  p  ir  e  1 

u  s  e  r  i  d 

.ACL  entry. 

In  all  h^st  commands,  the  pathname  passed  by  the 
Host  is  the  pathname  (relative  to  the  'root'  directory  of 
the  Host  virtual  file  system)  of  the  file  of  interest, 
whether  a  directory  or  data  file,  ^rom  the  pathname,  the  FM 
process  is  able  to  extract  the  pathname  of  the  parent 
directory  which  it  must  brina  into  the  FM  process  memory   to 
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ched'   for   proper   discretionary  access.   The  complete 

Pathname,  in  terms  of  the  r3S  file  system,  is  passed  to  the 
t)irectcry_Control  module  for  actual  directory  manipulation. 
s  pathname  and  file  size  'for  the  'tuffer  file')  is  returned 
fdir_pat hname,   dir_f ile_si ze )   ty   the   Directory_Control 

module  during  a  *Jost  RFJD_FIL?  cr  STORE^H F  reauest.  This 
new  pathname  a^  file  size  is  passed  to  the  10  process  where 
the  actual  data  transfer  takes  place  for  these  operations. 
Since  discretionary  security  checks  are  made  in  the  FM 
process  and  all  input/output  "t-uffers"  (e.g.,  temporary  data 

file,  rnail_hn'»'  segment)  are  under  positive  FM  process 
control,  the  TO  orocess  need  not  he  concerned  with 
discretionary  security  or  the  possibility  of  a  "sermcnt 
fault  ' . 

A  link  is  a  pathname  which  a  Host  passes  in  the 
b?.E»TE_LINS  command. 

File  type  is  used  for  the  CRF.4TF_FILF  Host 
command  ard  is  necessary  hecause  of  the  different  file 
formats . 

Command  type  is  used  in  the  ?.FAr_?ILE  Host 
command  to  specify  the  type  of  'read'  the  F5S  is  to  conduct, 
i.e.,  to  read  a  directory  file,  a  data  file,  or  only  a  data 
file  size . 

File  size  is  passed  hy  t^.e  Host  during 
STC?.E_FIL2  reouests.  This  information  is  necessary  :"or  the 
Fr"  process  tc  create  a  temporary  file  of  sufficient  size  to 
store  a  Host  file.  File  size  is  relayed  to  the  10  orocess  so 
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that  the  10  process  can  ^o  directly  to  the  lata  file  without 
jjaving  to  chpc^  fhe  directory  file  for  file  size.  File  size 
is  in  ci  ts  . 

Access  level  is  "ep,ie-  for  the  CHEAT 3  FILE 
command.  This  allows  for  upgraded  directories  ^remember, 
iata  files  cannot  he  upgraded). 

The  identification  of  the  Host  system  user  is 
necessary  for  the  FSS  to  perform  discretionary  security 
checks.  This  is  provided  by  the  Host  system  through  the 
userid  paramet er  . 

ACLj5>try  i5  use^  w i  t h  the  •'  DD_  !  CL_SNTEY  and 
foViTrrnvji  CL_ENTRY  commands  to  sive/rescind  discretionary 
access  +  o  f i les  . 

b.   Directory  Control  Module 


The  Directory_Control  module,  as  the  na'ne 
implies,  ices  the  directory  manipulation  and  maintenance. 
Figure  11  lis*;  the  procedures  which  'vnKe  up  this  module 
along  with  their  input/output  parameters. 

This  ic  fhe  level  of  the   I'M   process   at   which 

files  are   known.   The  Directory_Con tori  module  handles  tne 

J 
readers/writers  problem  with   the   appropriate   use   of   the 

kernel   syncroni  zation   primitives  READ,  ADVANCE.  A'*  A  IT,  and 

TICKET.  It  handles  the  sesmert  fault  condition  by  a  call   to 

the   condition  establisher  when  the  possibility  of  a  segment 

fault  exists.  The  10  process  uses  the  same  primitives   while 

'oerformin^   its   portion   of   the   lata   file  read  and  store 
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operations,  viz.,  the  tree  traversal  when  locating  the  date 
file  read  buffer  or  the  temporary  storage  file.  £s 
previously  Te^ti^ne^,  the  IC  process  will  not  face  the 
orohle^  of  file  deletion  while  reading  and  will  therefore 
not  have  to  establish  a  condition  handler. 

Logically,  rjost  reauests  reauire  four  basic 
actiors  to  he  pprf  nr^ori  at  this  level.  They  are:  1)  to  bring 
a  directory  file  into  "Process  memory  for  a  read  and/or  write 
ooeration,  2)  to  delete  a  file,  3 )  to  create  a  file,  or  4) 
to  copy  a  data  file  into  a  data  file  buffer.  411  other  file 
TiairteT"arce  fur^tio^s  such  as  managing  memory  or  managing 
the  limited  number  of  segments  available  to  a  process,  arP 
performed  by  subordinated  modules.  There  are  three 
procedures  in  this  module. 

The  Bir_Cntrl  Directory  procedure  is  the 
Di  rec  t  ory_C  o^+  r*"1 1  module  procedure  which  handles  Host 
commands  which  reouire  tha+  the  oarent  directory  he  broueht 
into  process  memory  in  order  that  reauired  discretionary 
security  checks  can  he  made.  These  Host  commands  are: 

TEL^TE^FILE 

CFE5TT_EILE 

CR?«TT?_LINK 

HEAT_EILT  (dir,  size) 

ADD„ACL_ENTRY 

T)TT-p.TE_*CL_ENT?.Y. 

To  uerform  these   tasks,   the   parent   directory 
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segment      (which   contains    the   file   branch/link    entry)    must    b< 


b  r  o  u  £■  b.  t      into        nro^ess        n^norv        to        c  h  e  c  ,-r 


or 


iro^er 


discretionary  access.  If  access  is  permitted,  the 
oesrner.  t_  Handler  module  is  called  with  a  pathname  of  a 
segment  reauired  to  be  brought  into  process  memeory. 

For  action  or  a  DEL3T]C_TI1E  command, 
discretionary  write  access  to  the  directory  is  reauired 
since  the  branch/link  entry  of  the  file  must  be  removed  fro^ 
the  directory  when  the  file  is  deleted.  (Note  that  this 
raises  the  possibility  of  a  Host  having  write  access  to  a 
file  hut  not  able  to  delete  it  because  he  does  not  have 
write  access  to  the  directory.;  If  the  parent  directory  file 
is  not  found  or  found  but  write  access  to  the  directory  rot 
permitted  an  appropriate  error  code  is  returned,  viz.,  "file 
rot  found   nr  write  access  not  permitted 

If  an  error  condition  does  not  arise,  the 
directory  is  brought  into  process  memory  ard  a  cheo>  of  the 
file  attributes  is  Tale  to  determine  file  type  (data, 
directory,  link).  Tf  it  is  a  data  file  or  link  entry,  it  car 
be  deleted  because  it  is  a  terminal  node  in  the  filQ 
hierarchv.  If  it  is  a  directory,  the  (directory)  file  itself 
must  be  brought  into  process  memory  to  see  if  the  directory 
is  empty  'viz.,  check  of  Tntry_Count  and  presence  of  a 
Supervisor  temporary  file':.  If  it  is  not  empty,  an  error 
code  of  "not  terminal  file"  is  returned  to  the  Host.  If  the 
directory  is  empty,  it  can  be  deleted. 

If    r  o   error    condition   occurs   during   the 


preceding  checks,  the  file  ^ay  (subject  to  check  by  the 
Kernel)  be  deleted.  The  Dir_Cr.trl_Directory  procedure  will 
call  on  Se2_"nd_,v|ake_Unaidres5able  procedure  which  will  in 
turn  call  !v!em_H*i^_Swapcut  orocedure  to  remove  the  segment 
from  process  memory  if  it  is  in  memory.  r?.emenber  the  actual 
order:  Swap_Ou*,  Terminate,  Delete.)  Mert ,  the  Kernel 
primitive,  GateKeeper .Delet e_Segmen t  is  called  to  delete  the 
file  fron  the  735.  Hnte  that  in  the  case  of  ^s^'s,  thcse 
steps  must  be  repeated  until  all  segments  of  the  file  are 
deleted.  At  this  time,  the  branch  entry  is  removed  from  the 
directory  by  zeroina  all  branch  entry  elements  'to  allow  for 
Kernel  secondary  ?tora?e  corpacticr  of  disc  pa^es  of  zeros). 
The  10  process  is  then  instructed  to  acknowledge  the  Host 
with  "file  deleted".  This  frees  the  entry  for  future  use. 


The   deletion   of 


link  requires   the   same 


discretionary  writQ  access  + o  the  directory.  In  this  case, 
no  further  checks  are  necessary  and  the  link  entry  elements 
are  zeroed  in  thp  directory,  freeing  the  entry  for  re- use. 

"or  the  "R^'TF^IL^  command,  analogous  action  is 
take"  by  the  Dir_Cr.t,rl_Di  rect  ory  procedure,  viz.,  to  check 
discretionary  write  access  to  the  directory  which  will 
contain  the  file  branch  entry. 

Once  this  check  has  been  satisfactorily 
completed,  a'-d  ronp  ^Tists  in  the  directory,  the  Kernel  call 
Gatekeeper . Create_Se2ment  is  made  to  create  the  file.  The 
initial  file  size  is  zero  for  data  files  since  the 
Supervisor   has   no   prior  knowleds-e  of  the  size  of  the  file 
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trat  will  be  stored  ir  the  branch  entry.  As  explained 
earlier,  a  file  size  of  L.^RSZ  (SK  bytes)  was  selected  'or 
the  fixed  I i rectory  size. 

The  C?.EATE_LINK  reauest  is  again  analogous,  the 
only  difference  being  that  instead  of  a  branch  entry  bein? 
~?ade  ir  the  directory,  a  lirk  entry  is  *^aie.  .^s  previously 
mentioned,  the  Supervisor  will  not  allow  a  loon  state. 
Checks  will  *»*t  be  made  at,  link  creatior  time?  however,  the 
Supervisor  will  'abort'  a  file  search  if  it  encounters  this 
error  condition  d u r i n s   tre°  traversal. 

The  Rr'5*,|_'IrILr  Mir;  command  reauires  read  access 
t r  a  directory  file.  If  no  err,ir  condition  arises  during 
discretionary  security  checks,  selected  directory  data 
'e.g.,  Entry_Name,  ?ile_Siz^,  etc.}  is  transfered  to  the 
Host  system  via  the  mail_box  segment  (viz., 
Dir_Cata_3uf fer ) .  This  selected  directory  data  for  each 
'occupied'  branch/link  entry  is  transfered  during  the 
t~AD_YILT  dir)  command.  Tor  the  :1E^_!_?IL"  (size)  reauest, 
only  selected  directory  data  for  a  specific  data  file  is 
transfered.  The  IC  and  FM  orocesses  use  appropriate  Kernel 
synchronization  primitives  to  assure  that  the  information  in 
the  mail_box  segment  is  valid. 

The  last  thr^e  Host  reouests  handled  by  the 
Dir_C!ntrl_Direct  ory  procedure  are  related.  Again, 
appropriate  discretionary  access  checks  must  be  ^ade  in  the 
parent  directory.  If  no  error  condition  arises,  the  action 
take'1   is   straight   foreward.   Ir   the  case  of  the  ?.E'D  "CL 
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command,  the  file  4CI  is  transferee!  tc  the  nail_to:<: 
3,CL_buffer  aM  the  procdure  returns  to  the 
fM_Command_?andler  module.  In  the  case  of  the 
ADD(DELTriN  _ACL_ZNTRY  co^mar.d s .  the  actior.  is  completed  by 
the  Dir_Cntrl_Directory  procedure  and  the  appropriate 
Di r_Succ_Code  returned . 

The  T,i^_Cr.trl_"ata  procedure  is  responsible  for 
trar  sf  erir.g  to/from  a  Host  a  reouested  data  file  if 
necessary  preconditions  are  met  'viz.,  discretionary  and 
r.on-discret  i  onary  security).  Ir  order  to  read  c^  store  a 
file,  a  Host  must  have  the  proper  discretionary  access  to 
the  file.  To  check  this,  the  parent  iirectory  which  contains 
the  file  branch  entry  must  he  broueht  into  memory.  This  is 
done  by  the  Ses^e^t  Handler  module.  If  the  proper  access  is 
rot  allowed,  a"  error  code  is  returned  to  the 
EM_Commar.d_Kardlp,~  module  for  relay  to  the  Host  system.  If 
the  proper  access  is  allowed,  a  cooy  of  the  file  is  made  in 
the  case  nf  the  ?. E .a D J? I L E  command,  or  a  temporary  file  is 
created  in  the  case  of  the  STCR?_"R'ILE  command.  The  pathname 
and  file  size  of  the  data  ^iles  to  be  transferee  are  passed 
to  the  10  process  which  will  perform  the  actual  data 
transfer.  Upon  a  successful  transmission  of  the  data  by  the 
10  process,  tbe  VM.  nrocess  instructs  the  10  process  to 
acknowledge  the  Host  with  a  "read  complete"  or  "store 
complete',  as  apurouria te . 

The  Eir_Cnt rl_Data  procedure  will  make 
appropriate   use  of  kernel  synchronization  primitives  {e.s., 
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&WAIT,  R7.aD,  etc.)  when  copying-  a  lata  file  into  the  data 
file  read  buffer  "t  setting1  up  a  temporary  file  for  the 
store  operation.  After  the  file  transfer  has  ta>er.  ulace  in 
the  10  process,  the  IC  process  returns  a  success  code  to  the 
T  process.  The  10  process  will  return  to  the  FM  process 
vher  one  of  three  conditions  evist :  1)  pither  the  real  or 
store  operation  is  successful  and  complete,  or  2}  a  command 
packet  is  T'eceil^a',  (viz.,  a*1  abort  command),  or  3)  a 
'time-cut'  occurs  and  the  10  process  was  not  able  to 
complete  the  command . 

7or  a  store  operation,  the  Dir_Cntrl_Update 
procedure  is  "ailed  to  update  the  directory  data  (viz., 
exchange  the  temporary  file  ?ntry_Name  with  the  old  file 
Entry_Name)  and  deletes  the  old  file.  (The  temporary  file 
should  be  deleted  by  this  procedure  if,  upon  attempting  to 
update  the  file,  the  old  file  cannot  be  found.) 

Since  eacln  directory  segment  has  only  one 
temporary  file  for  file  update,  s^me  delay  may  be 
experienced  by  ^ost  systems  if  several  try  to  store  lar-sre 
files  into  the  sa-^e  directory.  This  does  rot  appear  to  be  a 
major  problem  since  most  users  are  anticipated  to  be 
operatirg  fro^  their  own  directory  files. 

The  *Hr_nntrl_Update  procedure  is  also  used  to 
free  the  temporary  storage  file  in  the  case  of  a  Host  abort 
command . 

c.   Discretionary  Security  Module 
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The  T,iscretior.ary_Security  module  is  responsible 
for  checking  Eost  user  discretionary  access  to  a  specific 
file  and  adding  and  deleting  .4CL_entries .  '-11  file  «CL's  are 
logically  located  in  this  nodule.  This  is  the  only  other 
nodule  besides  the  direct  or. y_Con  t  rol  "nodule  where  a  segment 
fault  nir-hf.  n^cn-*.  Appropriate  usa  cf  the  condition 
establisher  must  he  made  before  any  attempt  to  read  an  ACL 
sr  that  a  pr^p^r  return  is  executed  to  the  Directory_Cor.trol 
module  in  the  event  of  a  fault.  There  are  four  procedures 
vhich  make  up  this  nodule  a=»  depicted  in  figure  12. 

The  Di  sc_Sec_r'hec.<_5  cce  ss  procedure,  as  the  name 
implies,  checks  fAr  a  specific  user  discretionary  access  to 
a  specific  file.  a  success  cole  returns,  indicating  the 
result  of  the  check.  This  discretionary  check  is  only  made 
on  the  specific  file  which  is  reouired  in  a  Host  command, 
i.e.,  a  design  choice  was  made  not  to  make  discretionary 
access  checks  during  the  tree  traversal  search  for  the 
specified  file.  This  mates  explicit  in  one  ACL  who  has 
access  to  a  file,  which  contributes  to  clear  security 
semantics.  (This  also  eliminated  the  Question  of  what  to  do 
if  an  intermediate  directory  was  encountered  during  a  file 
search  to  which  the  process  did  not  have  read  access.) 

T'^e  Piso_Se^_'5dd_'CL_;Lnt  ry  procedure  adds  an 
ACL_entry  to  a  file  ACL  and  returns  a  success  code  to 
indicate  the  action  taken.  2s  noted  previously,  a  directory 
has  a  limited  number  of  ACL_entry  elements.  The  Supervisor 
only  guarantees  ore  SCL  entry  element  per  branch  entry   (for 
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PROCEDURE  INPUT  OUTPUT 

Disc_Sec_  ACL  Disc_Succ_coi  e 

Check_Access  ftCLJSntry 

U  s  e  r  i  d 


Disc_Sec_  ACL  Disc_Succ_Coie 

iddj  CI_Pntry  «CL_?ntry 

Userid 


Disr_Ser_  aCL  Pi sc_Succ_C ode 

Eelete_AGL_Sntry   ACL_Entry 

Userid 


Disc_Sec  A.CL_Er:  t^y  Disc_Succ_Code 

Set    Pntry  Userid 


Figure   IP.      Piscre ti onary_Securi ty  Module 
Procedure    In  put /Out  put    Parameters 
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the  fila  creator).  If  another  ACI_entry  15  reauired  and  t.ne 
&CL_entry  "nocl"  is  empty,  an  "CL_ertry  element  will  have  to 
he  explicitly  freed  from  a  file  ty  the  Host  before  a  file 
?CL  can  he  added  to. 

The  r'isc_Sec_"1elete_5  ^L  _r'n  t  ry  procedure  performs 
the  straight  foreward  task  cf  deleting  an  1CL_entrv  fron  a 
file  ACL.  This  prociure  returns  a  success  code  when  deletion 
is  complete . 

The  last  procedure  of  this  module  is  the 
Disc_Sec_Get_?CI  pT~edur°.  It  is  used  during  the  intial 
creation  of  a  file  ty  the  Direct  ory_  "on  trol  nodule  to  get  an 
irit.ial  ACL  Entry  element. 

d.   Segment  "andler  Module 

The  Segment _Eandler  module  is  the  abstraction 
level  at  which  Supervisor  segments  are  known.  This  module 
works  in  conjunction  with  the  r/emor,y_Handler  module 
'described  later)  to  either  bring  a  segment  into  process 
memory  (viz.,  Ma^e  Known,  Si>,ap_Ir)  or  to  terminate  a  segment 
(viz.,  Swap_0ut,  Terminate).  This  module  is  responsible  for 
maintaining  fhe  FM_KST  (known  segment  table — figur°  13)  data 
base.  The  data  base  elements  of  the  FM_KST  are  the  pathname 
of  a  segment  known  to  the  process,  the  segment  number 
'See_£'  of  the  terminal  file  in  this  pathname,  -rode  (i.e., 
reed  or  '>r  r  i  t  e  1  ,  and  the  use  bit  necessary  fen  a  LVJ  r^^oval 
algorithm  ( approximation ) .  Tn  prevent  the  situation  where  a 
segment  has   be0"   deleted   by   one   process   tut   is   still 
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See_* 
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Ti?uva    13.  TM  K5T 


PROCEDURE  INPUT 

Seg_^nd_  Pathname 

Make  Addressable 


OUTPUT 

Ses_* 
5eg_5ucc_Code 


Se,?_CInd_  Pathname 

Make  Unadd ressahle 


Ses   Succ  Code 


Figure  14.   Segment _?andler  Module 
Procedure  Input /Output  Parameters 
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indicated  as  i*1  rren"CT>7  by  another  process,  each  new  Host 
command  will  initiate  a  vernel  call,  Gatekeeper . Swap_In 
(Ses_#,  Base_cddr),  to  confirm  the  existence  of  a  segment.  i! 
Kernel  return  of  "segnp^t  not  found'  will  indicate  that  the 
segment  has  been  deleted.  The  "SS  must  then  clear  its  data 
structures  o ?  invalid  data  and  traverse  the  virtual 
hierarchy  fro^  the  root  directory  to  insure  that  the  segment 
is  truely  gone  and  that  it  has  not  teen  rename!  by  another 
process  i.e.,  +^  cover  the  unlikely  situation  where  a 
pathname  has  "been  deleted  and  then  re-created  with  the  same 
filenames.  This  would  associate  differert  segment  numbers 
with  the  same  pathname. 

Figurp  14  is  a  list  of  the  procdur°s  of  this 
module  along  with  their  input/output  parameters.  This  module 
receives  a  file  segment  oa^hname  and  returns  when  it  has 
been  brought  into  p-ocess  memory  or  an  error  condition 
arises.  The  possible  er'^r  condition  that  might  be  returned 
from  this  module  is  'file  rot  found'.  This  module  has  two 
tasks,  and  therefore  two  procedures.  To  make  a  segment 
addressable  by  the  ~ost  process  (viz.,  brins  it  into  process 
memory)  or  to  make  a  segment  unaddressable  by  a  Host  process 
'viz.,  to  remove  the  segment  from  process  memory).  The 
procedures  which  handle  these  tasks  are  the 
Seg_Hni_v,ake_Aidressable  'i.e.,  bring  a  segment  into  process 
memory'  a-.*  5e?_Hr,d_Make_Unaddres  sable  (i.e.,  remove  a 
segment  from  process  memory)  procedures.  '  <lote  that  to  ma^e 
a  segment  addressable   also   reo^ires   making   the   segment 
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Known  and  that  makir.a  a  segment  unaiiressable  reauires 
"terminating"  the  ser^e^t.  ')  3oth  tasks  are  accomplished  by 
apnronria te  use  of  Kernel  primitives  and  accompanied  by 
calls  to  the  f/,erri"ry_HaTi  il  er  module  to  Swap_In  or  Swap_0ut  a 
segment . 

This  nodule  is  also  responsible  for  segment 
management.  Segment  management  is  necessary  because  each  WMU 
allows  the  add^pssi*1,?  of  only  64  s  e  ^  e  *!  t  s  .  With  ore  M  M  U  ir 
the  initial  TSS  implementation  and  several  segments  taken  by 
the  Supervisor  a1"^  Kerne]  segments,  the  number  available  to 
the  Supervisor  orocesses  will  be  somewhat  less 
»'i^X_KNO'»N_Sr:':-,>  thai  64.  This  number  must  be  managed  ir  a 
dynamic  manner  without  interfering  with  process  execution. 

The  Se^_::rd_MakQ_Addres  sa hie  proceduT,a  is  the 
more  involved  of  the  two  module  procedures.  If  a  reauest  to 
make  a  segment  kr.^vr  is  received  ,  the  FM  K5T  is  checked  to 
see  if  it  is  already  known.  If  it  is,  the  LRU  bit  is  set  and 
the  Memory _Har.d ler  module  is  called  to  assure  that  the 
segment  is  in  orocess  memory.  If  it  is  not  already  known  to 
the  process,  it  must  be  made  known  by  the  Kernel  call, 
Gatekeeper. Make_Known  (Par_seg_^,  entry_#,  mode).  But  this 
can  only  be  done  if  process  segment  limit  is  not  exceeded. 
If  the  addition  of  a  segment  will  cause  an  overflow,  a 
seg~ert  must  be  removed  by  the  3e?_Hrd  _Nade_Unaidressable 
procedure.  Once  this  is  done,  the  desired'  segment  can  be 
rrade  known,  the  FM_KST  updated,  and  the  Memory  Handler 
module  called  to  bring  it  i"to  process  memory. 
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The  S*3g_Hnd_,v!ake_jna''dressable  procedure  is 
straight  foreward.  This  procedure  may  be  called  to  either 
delete  a  specific  segment  or  to  delete  the  LRU  segment.  If 
called  to  remove  a  specific  segment,  actior  is  taker,  to 
remove  the  segment  (described  below).  If  callei  to  remove 
the  LRU  segment,  a  LPU  removal  algorithm  'approximation)  is 
used  to  determine  which  segment  will  be  removed  J  '.'.'hen  this 
has  been  done,  the  Memory_Randler  module  is  called  to 
Swap_Cut  the  segment  fro^  process  memory.  A  returned  success 
code  indicates  that  the  segment  has  been  removed  by  the 
Kernel  call  3-atekeeper .  Swap_Cut  (Seg_#).  A  call  is  then  made 
to  termirate  the  selected  segment.  The  Kernel  call, 
Ga t ekeeper . Ter^i^a t, e  (Par  S^g  -,  Tntry  Kti)  ,  will  cause  the 
segment  to  be  deleted  from  the  Kernel  K3T.  Removing  the 
Segment  pathname  from  the  TM_KST  will  complete  the  action 
taken  by  this  procedure. 

o#   [■'p^iiry  Har^lPT"  Module 

This  module  operates  in  a  "slave"  mode  to  the 
Begment_Eardler  module  and  consist  of  two  procedures.  These 
procedures  are  listed  in  figure  15  along  with  their 
input /output  parameters.  The  job  of  this  module  is  to 
dynamically  manage  a  fixed  size  linear  virtual  memory.  It 
does  this  by  swapDin?  in  and  out  of  process  memory  segments 
as  reauired . 

When  the  Mem_End_Swap_In  procedure  is  called, 
the  FM  JST.  figure  If,  ''active  segment  table)  is  checked   to 
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Figure  15.   Memory_Randler  Module 
Procedure  I",  put  /Cut  put  Parameters 
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see  if  i +  is  already  in  memory.  If  it  is,  its  LRU  bit  is  set 
and  Gatekeeper .Swap_In  'Ses_#,  lase_°ddr)  is  called  tc 
insure  that  the  sp^^e^t  has  not  been  delete!  fcy  another 
nrocess  since  last  use.  If  the  segment  is  not  in  ne^ory,  the 
M"5!M_MAP  data  structure,  figure  17,  is  checked  to  find  rocn 
for  a  se^m<=r.t  of  the  reauired  size,  ftrguemerts  car  "be  made 
for  both  a  first-fit  aid  best-fit.  memory  management  scheme 
[Shaw],  i  first-fit  scheme  is  chosen  for  the  K3S  due  to  the 
simpler  implprrenation  and  +he  reduced  memory  fragmentation. 
If  room  cannot  be  found,  Mem_Hnd_Swap_0'Ut  is  called 
iterative!1/  until  enough  roc1^  erist  for  the  segment  to  be 
brought  into  process  memory.  ?  Kernel  call, 
Ga  tekeeper .Swapi"  {Sep_~,  3ase_Addr),  is  used  tc  move  the 
segment  into  crocess  memory  when  room  exists. 

^em_Hnd_Swap_Cut  may  either  be  called  to  remove 
a  specific  segment  or  to  remove  the  LP.U  segment  from  DrocQss 
memory.  If  the  reouest  is  to  remove  a  soecific  segment,  the 
task  is  straight  forevard:  a  call  is  made  to  the  Kernel 
primitive  Gatekeeper .Swap_Cut  (Seg_*).  If  the  renuest  is  to 
remove  a  snecific  segment,  a  LRU  algorithm  (approximation) 
is  used  to  determine  which  segrent  to  remove.  When  this  is 
done  the  Kernel  call  is  made  and  the  Memory_Ran dler  data 
'hases  ar?  updated  to  reflect  the  segment  removal. 

5  preliminary  analysis  of  memory  requirements 
indicates  that  process  linear  virtual  merrnry  will  need  to  be 
at  least  24K  bytes.  The  driving  factor  in  this  calculation 
is   the  fact  that  two  data  segments  'possibly  SK  bytes  each) 
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may  be  reauired  in  process  memory  during  the   copying  of   a 

lata  file  into  the  lata  file  "buffer" .  A  24?'  byte  memory 
woull  allow  for  the  worst  <~ase,  viz.,  or.e  SS  bytQ  se^Ter1: 
positioned  in  the  middle  of  linear  memory?  toot,  would  still 
exist  for  the  two  3X  byte  segments. 

6.      Inout/Out out  Process 


The  10  rrocess  is  the  second  of  the  two  processes 
which  act  OTi  behalf  nf  a  H^st  system  to  provide  a  reouesfed 
file  r.ar.a^pfner. t  service.  The  10  rrocess  acts  ir  a  slave  mode 


to  the  F M  o  r  ^  c  e  s  s  : 


■  e  c  °  i  ■ r  e  s   its   commands 


the 


process    via   the   shared   mail_hox:   segment   described   in 
connection  with  the  FM  process. 

The  10  process  is  responsible,  as  the  name  implies, 
for  all  input  and  output  between  the  Supervisor  and  the  Host 
systems.  The  10  process  is  ~o^pose1  of  five  modules  as 
depicted  in  figure  1?  (along  with  Kernel  calls).  Two  of 
these  modules,  Segment^andler  and  Memory_Handler ,  are  the 
same  modules  as  described  i^  th°  Fv  process  a^d  will  not  b° 
discussed  further.  Their  task  is  to  trir.g  into  the  virtual 
memory  of  the  IC  p^oces^  the  data  segments  into  and  from 
which  "ost  files  are  stored  or  read.  Note  that  since 
discretionary  security  checks  are  done  ir  the  ?v  process, 
the  IC  process  does  not  have  to  repeat  these  checks. 

Direct   invocation  of    the  Packet  Handler  ^  r  ^  u  1 a  from 

the  IC_Commani_-andler   module   is   uossible   to   send   Host 

acknowledgements" .   If   a  file  is  to  be  read  or  stored,  the 
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File_Haniler  module  is  first  called  to  perform  the  read  or 
store  operation. 

The  10  process  is  also  responsible  for  FSS-Host 
Drotoccl.  ^ata  is  transferee  between  Host  and  755  via  fixed 
size  packets".  Ther°  are  three  formats  for  these  pacxets: 
1)  a  synchronization  packet  format,  2)  a  commani  packet 
format  ard  ,  3'  a  data  packet  format.  Figure  19  gives  the 
logical  construction  of  the  data  and  command  packets.  The 
sy1"1  chr  or  i  zat  ior  pac^e*  is  left  for  later  design  in 
correction  with  the  desi^*1  for  a  nost  interface.  The  packet 
size  of  521  bytes  for  dafa  ar."<  command  packets  was  chosen  to 
maximize  lata  transfer  efficiency  at  the  expense  of 
ircreasirg  the  rnrnr^ard  pack°t  size.  Because  512  bytes  is  the 
size  of  the  smallest  Supervisor  segment,  this  was  chosen  as 
She  "unit"  of  data  transfer. 

5  protocol  must  ^xist  that  insures  reliable 
transmission  and  ^f^ceptior  "f  packets  by  both  the  sender  and 
receiver  in  the  FSS-Host  packet  exchange.  The  simplest 
protocol  that  will  handle  packet  transmission  is  to  transmit 
packets  one  at  a  time  and  wait  for  packet  acknowledgement 
before  sending  the  next  packet.  The  following  diagram 
illustrates  this  simple  protocol. 


Packet  (n)  — > 


Packet  'n+1)  — > 


Tirre 


< —  ic'*. 
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Operating  ir  this  fashion  is  extremely  inefficient, 
especially  in  the  transmission  of  large  data  files!  it  does 
not  allow  the  sender  to  send  rackets  before  an 
acknowledgement  is  received  nor  does  it  allow  the  receiver 
to  accept  rrore  that  one  packet  at  a  tine  (i.e.,  read  ahaad 
and  write  behind).  A  multi-packet  protocol  is  necessary  to 
take  advantage  of  a  read  ahead  and  write  behind  scheme. 

In  specif  in,?  a  multi-packet  protocol,  some  means  of 
distinguishing  individual  packets  rust  be  established.  This 
is   done   by  giving  each  packet  a  seouence  number  carried  in 

the  packet  heai°r.  The  receiver  returns  acknowledgements 
indicating  the  sentence  rubber  of  the  packet(s)  received  and 
accepted  (i.e.,  no  errors  detected).  The  number  of  packets 
that  may  be  transmitted  before  an  acknowledgement  is 
received  is  called  the  packet  "window  width".  Packet 
transmission  is  controlled  by  ar  algorithm  which  uses  packet 
seauence  numbers  and  the  window  width.  At  System 
initialization  time  and  anytime  a  command  packet  is 
received,  the  seauence  number  of  the  FSS  is  reset  to  zero. 
Thus  the  first  seouence  number  expected  by  the  755  upon 
system  initiation  fand  afterwards  upon  command  completion) 
is  zero. 

"^or  an  explanation  of  how  the  packet  window  works, 
let  Nft)  denote  the  transmitted  seauence  number  nf  the 
current  packet  and  let  N(t+1)  denote  the  next  expected 
seouence  number.  The  window  width  is  denoted  by  W.  At  the 
start  of  communication,  e.g.,  when  a  ^ost  sends  a  command  to 
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the  FSS ,  the  Host  is  allowed  to  transmit  packets  bearing 
seai:er.ce  numbers  in  the  ranae  d^H(t  )<"'>!.  The  receiver  expects 
the  packets  to  arrive  i~  correct  seauential  orler.  As  they 
arrive,  packets  are  checked  for  correctness  (at  both  the 
hariware  (rJSAPT)  and  software  level)?  an  incorrect  packet  is 
iiscaHQd  and  ^ay  he  considered  'lost'.  Let  tee  seouence 
number  of  a  particular  correctly  received  packet  be  S.  If 
3=N(t-|-l)  (i.e.,  the  expQrted  packet1*,  then  the  packet  is 
received  in  the  correct  seouence  a  n  i  it  should  be  accepted 
by  the  receiver  and  ar  acknowlei cement  sent  with  the  proper 
seouence  number  (in  this  case,  S)  to  the  sealer.  If 
S^U(tMl) ,  then  the  packet  is  a  repetition  of  a  packet 
previously  received  by  the  receiver!  the  second  transmission 
may  be  due  t o  ei+her  a  lost  or  delayed  acknowledgement.  The 
receiver  should  generate  another  acknowledgement  and  send  it 
to  the  sender  ard  otherwise  ignore  the  packet.  If  S.^'M(t  +  l), 
then  the  packet  is  aheaS  of  seouence,  indicating  that  an 
earily  pac>et  has  bee'  l^st'  such  a  packet  should  be  ignored 
and  an  "error"  acknowledgement  sent  so  the  packet  can  be 
ret ra^  smi  tt ed  . 

The  arrival  of  acknowledgements  at  the  sender  also 
ne°ds  to  be  discussed.  As  each  acknowledgement  arrives,  the 
sender  can  delete  the  copy  it  has  retained  of  the 
Corresponding  packet.  As  packets  are  acknowledged,  fresh 
parkets  can  be  transmitted,  i.e.,  when  packet  ?.  has  been 
acknowledged,  packet  W  can  be  sent.  Acknowledgements  can  get 
lost  in  transmission  as   well   as   packets.   If   a   received 
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acknowledgement  does  not  refer  to  the  earliest  transmitted 
packet  avaitin.£  a  cknowled  verier f ,  the'1,  in  this  protocol,  the 
sender  may  safely  delete  all  packets  up  to  and  including 
that  T,eferPricei  by  the  acknowledgement  •  Against  each  copy  of 
a  transmitted  packet  will  te  noted  a  time  (i.e.,  the 
time-out.)  by  which  time  the  packet  rust  fee  acknowledged. 
Failing  such  an  acknowledgement,  the  packet  must  te 
jre transmitted  with  its  original  seauence  number.  A  packet 
will  only  te  receive!  in  sequential  order,  so  it  will  te 
necessary  to  re^ra^s^it  n *"> t  only  the  earliest  unacknowledged 
packet,  tut  also  all  later  packets.  The  following  figure 
illustrates  this  protocol.  The  aueues  should  be  considered 
as  circular  with  automatic  wrao-around. 
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In  this   figure,   the   sender   is   node   A   and   the 
receiver   is  node  B.  Node  A  has  sent  out  packets  3,4,  and  5, 


the  last  of  which  is  still  in   transit   to   3.   Node   3 


:as 


received  all  packets  up  to  and  including  4.  It  has  just 
acknowledged  3  and  4  and  is  ready  to  accept  5,6,  and  7  when 
they  arrive  in  order.  When  node  A  receives  acknowledgement 
for  3  and  4.  it  will  te  able  to  transmit  successfully 
backets  5  and  7. 

This   pro+ocnl   insures   that  packets  are  handled  in 


ae 


seauential  order  which  will  insure  that  the  lata  is  receive! 
aid  stored  correctly.  It  also  assure?  positive  control  over 
the  receipt  and  transmission  of  packets?  a  necessary 
reaui rement  to  prevent  buffer  overflow  and  loss  cf  data. 

The  rernel  controls  all  the  hardware  assets,  as 
explained  in  Chapter  1.  Kernel  calls  are  therefore  necessary 
to  transfer  packets  between  the  FSS  and  the  Host  systems. 
The  format  of  these  T/errel  rails  are: 

Gatekeeper. Setup  (Buff_Addr,  Mode,  Status) 
Gatekeeper .Send_?acket  'Offset,  Status) 
Gatekeeper  ,Store_?acket  (Offset,  Status) 
Gatekeeper  .  Change_Byt  e_Coun  ter  (#_of_Bytes,  Status) 

Each  hardware  port  is  virtualized  into  a"  input  a^.d 
an  output  port.  Tach  virtual  port  has  associated  with  it  a 
unit  control  block  (UCB)  at  the  Kernel  level.   The   elements 


of  these  UC1 
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3yt e_Counter :  This  element  is  used  to  ieep  track  of 
the  number  of  bytes  that  have  been  transmitted  o"  received. 
This  counter  is  modulo  "packet  size"  so  that  oi.ce  packets 
are  synchronized,  they  should  remain  so.  It  can  be  altered 
by  the  Change_Byte_Counter  call  in  order  to  get  the  7SS  and 
Fost  back  into  packet  synchronization. 

Buff er_Add ress :  This  is  the  starting  addrpss  in  the 
input/out  buffer  where  rackets  will  be  plared  (incommine)  or 
taken  from  (outgoing).  It  is  initialized  by  thf3  Setup  Kernel 
call. 
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Tuf  fer_T.ensth:  This  element  is  the  length  (in 
packets)  of  the  if  put /output  buffer.  This  allows  the  Kernel 
to  perform  automatic  wrap  around  at  the  eni  of  the  buffer. 

Wir_dov_Width :  This  element  is  used  by  the  in  out  port 
UC3  to  prevent  buffer  over  flow.  Each  invocation  of 
Store_Packet  will  advance  the  window  and  allow  another 
packet  to  be  stored  into  the  10  buffer.  If  a  Host  system 
violates  protocol  by  sending  too  many  packets,  the  Kernel 
will  dump  them  to  a  "bit  bucket".  This  element  is  used  by 
the  output  port  to  control  the  number  of  packets  that  the 
PSS  is  able  to  send  to  a  Host  before  receiving  an 
acknowleicjerre'1 1 .  ilthoush  this  parameter  (viz.,  window 
width)  may  be  different  for  the  various  Host  systems,  it 
should  ^ot  char.se  often  and  car  therefore  be  set  at  system 
initialization. 

TTn~  a  sfore  operation  ( F  5  3  to  receive  packets),  a 
Setuo  call  is  used  to  set  the  input  UC3  base  address  to  the 
initial  storage  location  in  the  10  buffer.  A  Setup  call  is 
also  reauirei  to  set  the  output  "JCB  with  the  base  address  in 
the  10  buffer  from  which  acknowledgments  will  be  sent.  It 
should  be  noted  here  that  the  10  buffer  in  the  10  process  is 
the  location  that  packets  are  checked  for  errors  and 
"enpacketed"  or  "depacketed".  It  is  just  a  intermdiate  stop 
for  data  and  neither  the  final  destination  nor  origin  of 
da  ta  . 

Subseauert  Kernel  calls  to  Store_?acket  will  return 
the   location   of   the   next   packet   in  the  10  buffer  to  be 
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processed.  The  Kernel  will  store  ahead  into  the  10  buffer 
durine  the  store  operation  hut  will  not  over  write  the 
buffer.  That  is,  each  call  to  the  Kernel  will  indicate  that 
a  new  packet  location  is  open.  The  10  process  will  control 
which  packets  ''and  how  ma^y)  are  sent  to  the  ?SS  by  proper 
use  of  acknowledgements  'for  both  correct  and  incorrect 
packet s )  . 

Two  Setup  calls  a^e  also  necessary  for  a  send 
operation.  They  again  set  the  virtual  input/output  oorts  for 
the  transfer  of  packets  from  the  7S 5  to  a  Host.  Subsequent 
calls  to  Send_Packet  indicate  that  a  Pac.-cet  is  ready  to  be 
transmitted.  The  10  process  knows  whOTi  it  can  discard  a 
packet  by  the  acknowledgments   it   receives   from   the  Host 

The  f,hange_"Dyte_Coi,n  ter  primitive  is  used  by  the 
synchronization  p^ocedur0  t<"  shift  a  UC3  byte  counter  in 
order  to  bring  packet  transmission  back  into 
synchronization.  (Synchronisation  may  be  reauired  during  a 
temporary  communication  interruption  or  system  start  up.) 

The   following  is   a  description  of  the  three  'new 
modules  which  make  un  the  TO  process. 

a.   Input/Output  Command  Handler  Mrdule 

't  the  top  of  the  10  process  module  hierarchy  is 
the  IO_ComraTid  _Fand  ler  module  fsee  Appendix  C,  p.  117).  This 
module  is  responsible  for  the  interface  with  the  FM  orocess. 
Communication  between  the   processes   is   via   the   mail  bor 
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shared  segment  ard  synchronization  is  through  the  use  of  an 
eventcour.t  ard  the  Kernel  primitives  TICKET,  ?D7ANCE  aH 
AWAIT.  The  procedures  of  this  module  alon,?  with  their 
input/output  parameters  are  listed  in  figure  2?. 

The  TO_r,md_tTnd  procedure,  like  the  7^_Cmd_und 
procedure  a  case  statement,  routes  FM  process  instructions 
to  a  specific  TO^ommand^andler  procedure  for  action. 

The  procedure  involved  when  the  Host  command  is 
not  a  Rv^Vi_vJlv  or  STOR^Tl7  reauest  is  the  IO_CmdJ!nd_Ack 
procedure.  This  p'ore^u'10  is  able  tn  invoke  the 
?acket_Handler  -nodule  directly  for  performing  directed  (by 
the  Ff  process)  Hosf  acknowledgement  a^d^r  data  transfer 
from  the  shared  mail_tcx  segment. 

The  IO_Od_H-1_Send  and  IO_Cmd_Hnd_Store 
procedures  are  relatively  straight  forward.  They  provide  the 
IC-FM  process  interface  required  for  a  x2AD_FILS  or 
3T0r"F_TIL"  TJost  reouest.  ^oth  procedures  call  the 
?ile_Hardler  nodule  tn  po-fnr^  the  actual  file  manipulation. 

h.   "ile  T-Tandler  Module 

The  File_Eandler  module  is  required  for  file 
manipulation  in  the  TO  process  and  is  the  level  in  toe  IC 
process  a*  which  files  ar°  known.  The  procedures  which  ma>e 
up  this  module  alon^  with  their  input/out  out  parameters  are 
listed  in  fi<*ura  21.  3s  mentioned  ahove,  there  are  only  two 
Host  requests  that  reouire  the  10  process  to  bring  data 
files   into   uroce  =  s   men^ry.   These   are   READ  TIL  I   and 
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STORF_FTIF.  Note  that  since  file  size  is  tassel  from  the  Fv 
nrocess,  and  the  *he  access  to  the  data  files  involved  is 
controlled  in  the  FM  nrocess,  data  file  segments  can  be 
brought  directly  into  10  process  memory  a^d  any  requirement 
for  the  IC  process  to  access  directory  files  (other  than 
tree  traversal)  is  eliminated.  Because  the  terminal  nodes  in 
the  tree  traversal  are  controlled  by  the  FM  urocess,  the 
paths  to  these  terminal  nodes  will  not  be  alterable  until 
control  is  released  by  the  rM  process. 

The  Fi le_Hand ler  module  consist  of  two 
procedures,  "c,ile_TJnd__Send_'c'ile  'for  Host  command  R5AD_FIIE) 
and  File_H-d_Sto~p_File  (for  Host  command  S rORF_FILF) .  Both 
procedures  operate  in  a  similar  manner.  Upon  receiving  a 
pathname  a^d  file  size  ^ro^  the  FM  process,  these  procedures 
use  the  Segment  Randier  procedures  to  bring  the  necessary 
data  file  'segment(s))  into  process  menor?/.  A  call  is  then 
made  to  the  ?acket_Handler  module  to  transfer  data  from/to 
specified  segments. 

The  order  of  events  in  the  reading  and  storing- 
of  data  files  follows  the  following  sequences.  For  a 
R^KD_71LV  operation.  the  order  of  actions  ta'^en  by  the 
Supervisor  are: 

1)  discretionary  and  non-discretionary  checks 
are  made  in  *he  FM  process. 

2)  \  copy  is  made  of  the  data  file  into  a 
per-process  data  file  buffer. 

31  The  uathname  of  the   data   file   to   be   read 
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(remember ,  directory  data  is  read  by  the  FM  process)  is 
passed  to  the  TO  orocess  alor?  with  the  file  size.  The  10 
process  ca^  1efer^i"e  the  file  si?e  from  the  file  directory 
tut  by  passing  file  size  to  the  10  process,  this  stet>  is 
eliminated  for  the  10  process. 

4)  The  read  takes  place  in  the  10  process. 

5^  The  10  p^cess  returns  to  the  FM  process  with 
a  success  code  of  "read  complete"  or  an  appropriate  error 
code.  The  0"ly  reason  for  a  read  operation  to  fail  in  the  10 
process  is  the  receipt  of  an  abort  command  from  the  Host  or 
a  'time  out'  which  would  occii**  if  the  Host  stopped  sending 
for  some  unexplained  reason. 

6)  The  F  M  orocess  instructs  the  10  process  to 
acknowledge  the  "read  complete"  or  tc  send  the  appropriate 
error  code.  The  data  file  read  buffer  is  then  free  for 
further  use. 

If  the  operation  is  a  ST0ft3_FILE  operation  the 
following  steps  are  taken  by  the  Supervisor: 

1)  Dis ere t i nrary  and  non-discretionary  security 
checks  are  made  by  the  FM  process. 

2)  A  temporary  file  is  created  by  the  Supervisor 
large  enough  to  store  the  file  in.  appropriate  use  of  the 
synchronization  primitives  prevents  this  temporary  file  from 
being  used  by  Tore  than  one  process  at  a  time. 

3)  The  pathname  of  the  temporary  file  is  sent  to 
the  10  Drocess  and  tve  10  process  stores  the  file  into  the 
temporary  file. 


4)  The  10  process  returns  a  success  code  to  the 
t^  process  and  the  "^M  process  updates  the  directory  to 
reflect  the  new  file  (viz.,  Entry_Name  of  temporary  file  is 
changed  to  the  old  file  ?ntry_Name) .  The  old  file  is  then 
deleted  by  the  7M  process. 

5)  The  FM  process  then  instructs  the  10  process 
to  acknowledge  the  "store  complete"  .  There  is  no  reason  a 
store  operation  should  fail  other  than  an  explicit  abort 
reauest  by  the  Host  system  or  hardware  failure. 

c.   Packet  Handler  Module 

The  Packet _Hard ler  module  does  the  actual 
transfer  of  data  between  the  ^SS  and  the  Host  system  and  is 
the  10  process  level  at  which  the  concept  of  "packet"  is 
known.  The  procedures  of  this  module  alons  with  their 
input /output  parameters  are  listed  in  figure  22.  The  tasks 
that  this  module  must  perform  are:  1)  synchronization  of 
packets,  2^  err^r  detection,  2)  packet  acknowledgement,  and 
4)  transfer  of  data  to/from  Supervisor  segments.  Ti^ure  23 
is  a  finite  state  diagram  of  packet  transfer. 

The  synchronization  task  is  performed  on  the 
svstem  IPL  and  whenever  packet  synchronization  is  lost 
thereafter,  ^rror  detection  and  reauest  for  retransmission 
upon  error  detect in^  a^e  com pi i rectory  functions  which  are 
performed  on  every  packet  received  from  a  Host. 

Packed  transfer  during  synchronization 
procedures    is    in    ?rouus   of   three.   This   allows   the 
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synchronization  procedure  +^  besin  synchronization  in  the 
middle  of  the  first  packet  and  still  have  two  packets  to 
confirm  synchroni  zat  ion  when  it  is  achieved. 

Packet  transfer  of  command  packets  occurs  one  at 
a  time.  The  reason  for  this  is  that  each  command  oaci-tet  must 
he  acted  upon  in  a  synchronous  manner.  Data  packet  read 
ahead  and  write  behind  is  permitted  to  increase  the  transfer 
rate  of  data  packets.  The  number  of  packets  that  are  allowed 
to  be  sent  or  stored  depends  on  the  IC  tuffer  size.  The 
?acket_Handler  module  is  also  responsible  for  data 
"enpacketins"  and  "depacketing"  for  the  FSS. 

The  ?k_Hnd_Synr  procedure  is  used  to  synchronize 
packet  transmission.  It  is  explicitly  called  at  I?L  and 
wherever  the  packet  synchronization  is  lost  by  the  Host 
systen.  It  is  invoked  implicitly  by  tha  FSS  whenever  a 
packet  is  not  able  to  be  decoded  'viz.,  the  packet  type  and 
packet  check-sum  are  incorrect). 

The  ?k_End_Ack  procedure  is  used  to  send 
acknowledgements  to  the  ^ost  systems.  This  procedure  will 
always  be  called  ''•o^  the  IO_Command_Handler  module  which 
will  reauire  the  ?acket_Eandler  module  to  either  acknowledge 
the  Host  with  a  specific  message  or  to  send  some  data 
located  in  a  mail_box  segment  buffer  to  the  Host. 

The  Pk_Hnd_5end  procedure  is  used  to  transfer 
data  segments  from  the  FSS  to  a  Host  system.  This  procedure 
is  called  from  the  File_Handler  module  which  makes  sure  that 
the   correct   data   segment   is   in   process   memory  for  the 


97 


transfer,  The  segment  number  along  with  the  number  of  "bits 
that  are  reouired  to  be  transferee!  are  passed  to  this 
procedure  from  the  File_Handler  module.  This  procedure  then 
transfers  the  sesment  until  the  specified  number  of  bits 
have  been  transmitted.  A  success  code  is  returned  when 
action  is  complete. 

The  ?k_TTnd_S  tore   procedure  worlcs   in  a  manner 
completely  analogous  to  the  ?k_Hnd_Eead  procedure. 


III.   CONCLUSIONS 
ft  .   STATUS  07  RFS^SCH 

This  design  applies  state  of  the  art  software  and 
hardware  to  solve  the  secure  multilevel  computer  problem  in 
a  file  storage  system.  It  presents  an  inexpensive  but  highly 
nowerful  design  for  a  system  based  on  a  micro-computer  tut 
not  restricted  to  a  micro—ccmDuter  environment,  i.e.,  there 
is  ro  rastictior  on  the  type  of  Host  computer  system 
serviced  by  *he  3TSS.  Implementation  of  this  design  en  Z8002 
hardware  along  with  the  analysis  of  ?SS  design  parameters 
(Appendix  ft )  are  f  a  s ,j"  s  left  to  be  Ice. 

There  are  two  major  classes  of  applications  for  the  FSS. 
One  application  uses  the  YSS  as  a  system  file  system  (e.g.. 
for  distributed  micros ^.  This  implies  that  the  total  system 
is  ^ul t i  1  eir el  secure  with  nrily  one  securQ  component  (viz., 
the  Kernel).  It  must  be  noted,  however,  that  in  this 
configuration,  the  distributed  Hosts  (i.e.,  the  micros)  have 
no  autonomous  life. 

The  other  class  of  applications,  involves  using  the  JSS 
as  ore  element  of  a  net  of  autonomous  Host  systems.  In  this 
Configuration,  the  FSS  provides  facilities  for  controlled 
data  sharing  ard  communication. 

An  obvious  direct  application  of  the  FSS,  is  for 
shipboard  use  !e.s.,  for  the  5;\.8?-II  system  [Smith])  or  for 
use  at  other  installations  where  data  would  be  more 
efficiently  used  if  controlled  lata  sharing  were  allowed. 


C.C 


8  major  desisrn  choice  of  the  ?33  which  allowed  the 
Kernel  to  he  kept  small  'and.  therefore  more  easily 
veTif iatle> ,  was  the  elimination  of  the  discretionary 
security  from  the  rernel  domain  to  the  Supervisor  domain. 
The  implication  of  this  choice  is  that  each  Host  system  is 
responsible  for  its  own  discretionary  security;  not  an 
unreasonable  recuest  or  design  choice. 

The  ne^t  major  task  to  he  accomplished  in  this  project 
is  FSS  implemen t at i on .  This  will  not  he  a  trival  task,  cut 
it  is  felt  that  the  designs  Dresented  in  this  thesis  and  the 
companion  work  done  by  Colenan  provide  a  solid  basis. 

3  .   FOLLOW  ON  WORK 

This  desir*1  is  a  specific  implementation  of  one  member 
of  a  family  cf  oneratir,s  systems  based  on  the  Security 
Kernel  concept  discussed  by  0'Cci.nell  and  ?.i chard  son 
[O'Connell].  Ther?  are  obvious  areas  that  this  design  could 
be  expanded  and  generalized"  areas  that  should  be  e^a^i^e^. 
after  a  successful  first  implementation.  Some  of  these  areas 
are : 

'operator'  terminal  interface  funcior.s 

expardei  H^st  corr"nari^s 

map   of  different   'user'  names  in  different  Hosts  to  a 
common  "user"  in  the  ^SS 

data  cnnpac*io^  onto  secondary  stnrar^Q 

multilevel  nosts 

moving  discretionary  security  into  the  Kernel  domain 
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dynamic  tjt^cpss  creaf  io"  'deleti  or  . 
These  are  just  a  few  of  the  many  possible  areas  ror 
e^pansio^  that  cmil r?  "be  explored.  0re  area  not  mentioned  in 
the  list  tut  an  area  that  should  be  looked  at  luring  the 
initial  i mule^er ta +icn  is  for  a  way  to  prevent  the 
Supervisor  from  suffering  a  '-segment  fault*.  The  present 
arrangement,   with   a   fault   handler,   is   not  efficient  or 

elegant  '.  Si^ce  the  deletion  of  a  segment  is  controlled   by 
the   Delete  Segment  Kernel  primitive,  a  method  of  leaving  an 

'orphan'  copy  in  crocess  memory  would  eliminate  the  fault 
cor di  t  i °n  .  The  o^ly  operation  that  would  he  defined  on  this 
'orphan'  would  he  a  r'elet e_ Segnen t  command  by  a  co^ess  to 
remove  if  from  process  mem^ry.  After  it  had  teen  deleted  by 
all  processes,  the  cony  could  te  destroyed,  g  variation  of 
this  scheme  would,  upon  a  Kernel  Swap_Ir.  call,  swap  into 
process  memory  a  per-process  copy  of  the  desired  segment. 
Swap_Cut  would  te  used  to  free  process  memory. 


1«1 


iDpr^Tjjy    a — SYSTEM   P  3R -"  M^T  ^RS 


SVALL 

MITT)  JTJ^ 

MAX_?ILE_SIZT 

MAX_ENTRY 

HCL_POOI 

Pat hi  ens th 
?n  try_Nane 
Known    Segments 


Segment    size 
Segment    size 
Segrnen  t   size 
Max    file   size 
ygT   i  i  r   en  t r  i  es 

Max  P.cl_!!n  tries 

per  directory 

Mar 

Size 

^a^  per  process 


512  bytes 
21   bytes 
5 X  bytes 
25^?  bytes 
32 
1024 

12?  bytes 

1?  bytes 
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CODE 


APPFMLIX  E — SJCCESS  AND  EiiROS  CODES 

LOCATION 


pile  Delete! 
File  Created 
Link_Created 

St  ore_CcrT,plete 

P.ead_Complete 

5r,L_Reed_Complete 

ACL_E^trv_Adde;' 

».CL~Entry~Deleted 

Cmd_* tor  ted 

Crnd  Packet  Expected 

Illegal_Cmd 

II legal _Cmd_?ormat 

File_Mnt  Fourd 
Mot  Terminal  Tile 


FM_Command_Eandler 

Module 


Li  rec  tory  Control 

Module 


Vri  te_Acces  s_Nl  ot_Al lowed 
-ead    Access    Not    Allowed 


Di  scret  ionary_Securi  ty 

MM  ule 


Time_Out 
^o_Sync 

?acket__Ack 
Packet    "rror 


Pa  eke  t_TTandler 
Module 
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APPENDIX  G 

FJM_C0MtfAND_HANDLE5  MODULE 

CONSTANT 
EALSE  :=  0 
TPUE  :  =  1 
NULL  :=  9} 

EXTERNAL 

DIP.  CNTRL  DIRECTORY  PROCEDURE  'MSG  3YTS 

USERID       BYTE 

PATHNAME     STRING 

EILE_TY?E  BYTE 
ACCESS  LEVEL  BYTE 
LINK  STRING 

ACL  ENTRY     ?CL_TY?B) 
RETURNS  /T,IR  SUCC  CODE  ^YTE) 

!for  host  ends  that  require  parent  directory: 

delete_f ile . 

create_f ile , 

creat e_liTi^  , 

read_acl , 

add_acl_entry , 

,ielete_acl_e",itT,y! 

DIR  CNTRL  DATA  PF.OCEDUFE  (MSS  BYTE 

USERTP  ^YTE 

PATHNAME  STRING) 

EILE_SIZE  LWORD) 

RETURNS  'DIP  SUCC  CODr  "°YTE 

DlR~PATHNAME  STRING) 
!for  host  CTids~that  access  data  file: 
read_f ile . 
store_f ile! 

DIR_CNTRL  UPDATE  PROCEDURE  'MSG-  BYTE 

USVRID  BYTE 

PATHNAME  STRING) 

PETUPNS  fDIc_SUCC_CODE  BYTP) 
!to  update  directory  after  io  process 
acts  or  host  cmds:  read_file,  store_file, 
abort ! 
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GLOBAL  Jmodule  entry  noint! 

FM_CMD_HND  PROCEDURE  'case  statement  on  Host  cmis  ' 

3NTRY 

DO 

VflT  1     p 

MAIL_3 
MAIL  3 
MAIL-? 

t  :=  S 

g3teke 

GATEEF 
IF  MAI 

THIN 


OX. MSI. INST  :=  EEAD_CMD 
OX. MSG. PATHNAME  :=  NULL 
OX. MSG. FILE  SIZE  :=  NULL 
OX.MSG.SUCC~CODE  :=  NULL 
ATEXEEPER. TICKET  [MAIL  BOX, 
FPEF. ADVANCE  (MAIL  BOX^  S^ 
EPFR. AWAIT  (MAIL  ?OX,  C,  (t+2)) 
L  BOX. MSG. INST  =  CMP  ?K  READY 


) 


jv   post  HMD 

SE  PFLET^_FILE  THEN  3V_CMD_HNT  EEL3T3_FILE 

S3  CPEATE  FILE  THEN  FM_CMD_HND  CREATE~FILE 

c;t?  fR^T7  LINK  THEN  FM  CMD  UND~CR3  AT7  Lll'.v. 

S?   R3AD  FILE  THEN  Fv_C^r_HND_aEAI  FILE 

S3  STORE  *IL3  THEN  FM  CMD  HND  STOP E_FILE 

Sv   RFAD»>L  THFN  FM  CMP_HND  RE«D  A.CL 

S3  ADD  ACL  ENTRY  THFN  FM_CM3_HND  ADD  ACL  ENTRY 

53  DELETE  *CL_FNT!-,  Y  THEN  FM  CMD  END_DEL,rTF  &CL  ENT.i  Y 

SF  a^ORT  T^N  FM  CMP_HND_AFO"RT 

IL_BOX.MSC-.INST  :=  ACK  HOST 
IL  BOX.MSG.PATEN»MF  :=  NULL 
IL_30X.MSG.FILF_SIZ?  :=  NULL 

IL_BOX.MSG.STTCC_rCD^  :-  ERROR  CODE  (ILLEGAL  CMD) 
:=  C^T^F^P^R  .TKtET  (MAIL  POt,  C) 
TEKEEPEP  .  iPVANCF  (MAIL_3CX,  C) 
TEKEEPEF. «WAIT  (MAIL  30X ,  C,  (t+2)) 


CA 
CA 
CA 
CA 
CA 
CA 
CA 
CA 
CA 
3LSF 
MA 

MA 
MA 
t 

CA 
CA 
FI 
ELSE 
MAIL 
MAIL 
MAIL 
MAIL 
t  :  = 
GATE 
GATE 
FI 


BOX.MSG .INST    :=    &CE   HOST 
"BOX.MSC.PSTHNAMF    ?=~NULL 
_3CX.MSG.FILT_SIZE    :  =   NULL 
_BCX.M5G.SUCC    CODE    :=    EI-iROR   CODE    (CMD   ?I   EXPECTED) 

CATT,FT'5,PT'R. TICKET    'MAIL    POX,    C) 
KEEPER. ADVANCE    (MAIL_B0X,    C) 
KEEPER. AWAIT    (MAIL    BOX,    C.     (t+2)) 


or 
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INTERNAL 

MSG    =   "PYT7 

FM_CMD_HND_DELETE_FILE   PROCEDURE 
ENTRY 

MS"    :=   T}vr)vi>vj?iiv. 
DIR_CNTRL_EIRECTCRY    (MSG 

USERID 

PATHNAME 

NULL  !file_ty?e! 

MULL  !access_level ! 

NULL  Hinkl 

NULL)  !acl_entry! 

Ireturns  dir  succ_code! 
IT  DIR  SUCC_SO?*  =  TRUE 

THEN 

MAIL   BOX.  MSG.  INST    :=    ACK  HOST 

M*IL_?OX. MSG. PATHNAME    :  =    NULL 

MAIL~BOX.MSG.FILE_SIZE    :=   NULL 

MAIL    BOX. MSG.SUCC~CODE    :=    FILE   DELETED 

t     :=    GA.TEKETER. TICKET    I'M  AIL    BOX  ,    C) 

GATEKEE?ED.ADVANCE  (MAIL_3GX,  C) 

GATEKEEPER . AW, A  IT  (MAIL  BOX,  C,  (t+2)) 
TLSE 

MAIL_3CX.MSG.INST  :=  A,CK_HOST 

MHL_BCX. MSG. PATHNAME  :=  NULL 

Mfl.IL  BOX. MSG. FILE  SIZE  :=  NULL 

MAIL_3CX.MSG.SUCC_C0EE  :  =  ERROR_COBE  (DIR_SUCC_COBS 

!file  not  found;  write  access  to  directory 
not  nermi tted ! 

t  :  =  GATEKEEPER. TICKET  'MAIL_BCX,  C) 

GATEKEEPER.  *D7 A NCE  (MAIL  30X"i  C) 

GATEKEEPER. AW AIT  (MAIL  BOX,  3,  (t+2)) 
EI 
END  EM  CMD  END  DELETE  FILE 
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FM_CMD_FND_CF.EATE_1:,ILE  PROCEDURE 
p.NTRY 

MSG 

DIR  CM 


CREATE  FILE 
ITRL  DIRECTORY 


! retur 
IF  DIR 
THEN 
MAIL 
^AIL 
MAIL 
MAIL 
t  :  = 
GATE 

S-ATT 

ELSE 
MAIL 
MAIL 
MAIL 
MAIL 
!dir 
ret 
t  :  = 
G  A  T  F 
GATE 

FI 
END    FM    C 


(MSG 

US^RIP 

PATHNAME 

FILEJTYPE 

ACCESS   LEV^L 

'MULL    !link! 

NULL^  !acl_entry! 
ns  dir  succ  code! 
_SUCC_CODE  =  TRUE 

_FOX  .MS"- .INST    :=    »CK_HOST 

BOX. MSG. PATHNAME    :=   NULL 
'BOX.MSG.FILE_SIZE    :=    NULL 
_FOX.MSG.STjr",_r,Or>?    :  =   FILE   CREATED 

GATEKEEPER. TICKET    (MAIL   30X,    C) 
KEEPER .4DVANCE    (MAIL_BOX.    C) 
DEEPER  .  AW*  IT    (M*IL   'OX,    C,     't+2)) 

_B0X.MS5.IMST    :=    »CK_HOST 
FOX. MSG. PATHNAME    ;»   NULL 
_BOX.MSG.FILE_SIZE    :=    NULL 
_30X.MSG.SUCC_CODE    :  =   ERROR_CODE    (DIR_SUCC_CODE) 

ectory  not   found;    write  access   to   directory 

permitted?    directory   full! 
GATEKEEPER. TICKET    (MAIL_30X,    C) 
TTP-rprp  .  apv  a  yrv    (MAIL    EOX,    C) 


KEEPER.  AWAIT    (MAIL_BCX, 
MVi   HN7^    CREATE   ?ILV 


(t+2)) 
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ENTRY 
MSG 

DIR 


CREATE   LINT/    PROC^DUR17 


CN 


CREATE  LI  NX 
TRI    DIRECTORY 


!ret 

IF   D 
TR 

MA 
MA 

MA 

t 

GJ» 

GA 
ELSE 
MA 
MA 
MA 
MA 
!d 
n 
t 

GA 
GA 
EI 

END    FM 


SUCC    CODE   -   TFUE 


urns   dir    succ   co 

IE 

EN 

IL 

IL 


MSG 

USSRID 

PATEN  A.ME 

NULL    !file    type! 

NULL    Jaccess    level! 

LINE 

NULL)    !acl  entry! 

e! 


IL 
IL 

TE 
TE 


_BOX. MSG. INST    :=    ACE   HOST 
BOX. MSG. PATHNAME    :  =    NULL 
_?OX.MSG.^ILi;,_SIZ^    :=    NULL 

_3CX.MSG.SUCC_CCDE    :  =   LINK    CREATED 
GATEKEEPER. TICKET    'MAIL   BOX,    C) 

KEEPER . 'DV'NCt    fvaiL   BOX,    C) 

KEEPER. AW A  IT    (MAIL    RCX ,    C    't+2)) 


ILJBOX. MSG. INST    :=    anK_ROST 

IL_BCX.MSG.?MHNAME    :  =    NULL 

IL~BOX. MSG. PILE  SIZE    :»   NULL 

ILJBOX. MSG.SUrc_COD7    ?=    ^RROR_CODE    ( DIR_SUCC_COD  ■ 

irectory   not    found;    write   access    to   directory 

ot   permitted?    directory   full! 

:=   GAT'E^P^R  .TICKET    (MAIL    BOX,    C) 

TEEEEPER.  ADVANCE    (MAIL   BOX  "J    C) 

TEKEEPER.AWAIT    (MAILJBOX,    C,    (t+2)) 

CMD    HND    CREATE    LINE 


1?8 


FM_CMD  READ  FILE  PROCEDURE 
ENTRY 

I?  FILE  TY?e  =  P8T4 
THEN 

MSG  :=  READ  FILE 
DIR_HNTRL_^8T8  (MSG 

USSRID 
PATEN AME 
NULL)  !fil 
! returns  dir  succ  code,  di 
IE  DIF_SUCC_CODE  =  TRUE 
TUVH 
MAIL_BOX. MSG. INST  :=  REA 

MA IL~BOX. MSG. PATHNAME  :  = 
MAIL_?CX  .MSG. FILE  SIZE  i 
MAIL  BOX. MSG. SUCC~C ODE  : 

t  :=  GATEKEEPER. TICKET  ( 
GA  TttkeedtRl  .  JT!V  s  NCE,  'MaIL 
GATEKEEPER. AWAIT ' (MAIL  B 
IF  MAIL  BOX. MSG. SUCC  COD 
THEN 

MSG  :=  UP£ATE_READ 
DIR_CNTRL  UPDATE  ''MSG 

USER 

PATH 

!update  will  not  fail ! 
^8!L_'OX.MSG.IMST  :  =  B 
MAI L_30X. MSG. PATHNAME 
MAIL~BOX. MSG. FILE  SIZE 
MAI LJ^OX.^SG. SUCC  fCD7 
t  :=  GATEKEEPER. TICKET 
GATEKEEPER .A D7 A  NCR  (MA 
GATEK^EP'R .  a.W*IT  (MAIL 
ELSE 

MAIL  BOX. MSG. INST  :  =  A 

MATT,  t»  OX  . MSG.?8 T° NAME 

MAIL_30X.MSG.EILE_SIZE 

MAIL__30X.MSG.SUCC_C0DE 

!error  code  returned  f 

!file  rot  found  by  io 

file  read  aborted  by 

file  read  aborted  by 

cri3  packet  received! 

t  :=  GATEKEEPER .TICKET 
GATEKEEPER . SDVA KCV  'M8 
GATEKEEPER .AWAIT  (MAIL 

EI 

EL  SE 

MAIL_BOX.MSG.INST  :  =  SCK 
MAIL_RCX  .MSrr  .PATHNAME  :  = 
MAIL~30X. MSG. FILE  SIZE  : 
MAIL~BOX.MSG.SUCC~CODE  : 
Ifile  not  found: 
read  access  to  file  not 


e_size ! 

r_pathnarre,    i ir_f  ile_si  ze  ! 


D_EILE 

DIR   PATHNAME 
=   RIR_?ILE_SIZS 
-    NULL 
M»IL   BOX,    C) 

'OX,    c) 
OX,    C  ,    (t+2) ) 
E    =   TRUE 


ID 
MAME) 

CK    UCST 
:  =  ~'JQLL 

:=   NULL 

•  =  Rirsp    COMPLETE 

(MAIL_BCX,    C) 
IL_30X,    C) 
_?0X,    C) 

CK   HOST 

:=    NULL 
:=    NULL 

:=   MAIL_30X.MSG.SUCC_C0DS 
rom    io   process! 
process  » 

write? 
file  deletion; 

(MAIL  BOX,    C) 
IL_RCX,    C) 
30X,    C,     (t+2)) 


HOST 
"NULL 
=  NULL 
=  ERROR.CODE  (D  I  ?._SUCC_CODS  ) 

oermi t ted ! 
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t 

Gfl 
GA 

PI 
ELSE 

IF  F 
TH 
MS 
CI 


:=    G,;'TE*'FFPEP  .TICKET    ("«IL_30X,    C) 
1<pypvp-PT?  .  ar;v»  NCE    'MSIL   ""OX,    C) 
TEKEEPER. AWAIT    (MAIL    BOX  ,  "c  ,    (t+2)) 


ILS_TYPF    =   DIRECTORY 

TT\J 

T    t=   R  "^  a  T)    D I R 

a  cntrl  dirYctci 


!r 

IF 


EL 


eturrs   di^_succ 
■niR_SUCC_O0PE 

MAIL_BOX.MSG.IN 
MAILBOX. MSG. PA 

MAIL_BCX.VSG.FI 
MAII~B0X.MS8.SU 

!dir  data  trans 
acl<:ri^wlediP,p,rier 
t,  :  =  G  ATEKEEPEE 
Gat-Ki:,t,?~R  .  s.nv& 
GATEKEEPER. AWAI 
SE 

M5IL_^CX.MSG.IN 
MAIL_BOX.MSO.?A 
MAIL~BOX.MSG.EI 
MAILJPOX  .WS^  .SU 
!  d  i  r  e  c  t n r y  not 
read  access  to 
I  •  =  GATEKEEPER 
GATEKEEPER. ADVA 
3A.TEEEEPEP  .  AW?  I 


>RY    (MSG 

USEPID 

PA  T^N  *  ME  ) 

NULL    Ifile_type! 

NULL    !access_level ! 

NULL    'link! 

NULL)    !acl_entry! 

=   TRUE 

ST    :=    ACK_R"OST 

THIMSM17    :  =    NULL 

LE_SIZE    :=    NULL 

CC__CODF    :=   DIR_READ_COMPLETE 

fered    from   dir_fcuf fer; 

t    s  ont  ! 

•TICKET    'MiIL_BCX,    C) 

\irtr    ''mjil^-sox,    C) 

T    (MAIL_30X,    C,    (t+2)) 

ST  :-  AC"  HOST 
THNAME  :=  NULL 
LE__STZE  :=  NULL 

CC_CODE  :=  ERROR_CODE  (DIR_SUCC_COP  • 
f ourd , 
directory  not  permitted! 
.TICKET  'MaiL_BOX,  C) 
NCE  (MAIL  BOX^  C) 
T  (M*IL  SOX,  C,  (t+2) ) 


EI 

ELSE 
MS 
DIR  CNT 


:  n  .  —  n 


IF 


eturn 

DI^_ 

MAIL_ 
MAIL" 

MAIL 
MAIL" 


p?D  ENTRY  DAT? 
RL_DIRECTORY  (MSG 

USERID 

PATHNAME 

NULL  !file_type! 

NULL  !acceis_level ! 

NULL  ! li-nlc! 

NULL)  !acl_entry! 
s  dirsucccode! 
SUCC_C0l>E  =  TRUE 

BOX. MSG. INST  :=  ACK_HOST 
"BOX.  MSG.  PA  THNAME  :=  NULL 
POX.MSG.-IL^SIZ"  :=  NULL 
BOX.MSG.SUCC  CODE  :=  ENTRY  REAL  CCMPLET. 
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1    gVj 

ac 


GAT 

ELSE 
Ma  T 

MAI 
MAT 
MAI 
!fi 

t    • 
GAT 
GAT 
71 


try   data    trar.sf ered   fron   dir_bufferJ 
fenowled^ement    sent! 
=  GATEKEEPER .TICKET    MAIL   BOX,    C) 
EKEEPER.ADVNCE    MAIL    BOX"|    C) 
EKEEPER  .AWAIT    (MA.ILJPOX,    C,     (t+2)) 

L_P0X.MSCt.INST    :=    ACK_HOST 

L   BOX. MSS. PATHNAME    :=    NULL 

L_BOX.MSG.FILE_STZE    :=    ^JULL 

L_"POX  .*SG  .SUCC'CODE    :  =   ERROR_CODE    (DIR_SUCC_CODE) 

le   not    found;    read   access    to    file   not    permitted! 

=   G&.TEKEEPE13. TICKET    (MAIL   BOX,    C) 

vyvvvvv  miT,y inc.v    (MAIL    POXl    C) 

EKEEPER. AWAIT    fMAIL   BOX,    C,     (t+2)) 


71 
71 
END  EM 


CMD  HMD  HEAD  FILE 
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FM  CMD_HND_STORE_FTLE  PROCEDURE 

ENTRY 

MSG    :=    STOR^IL^ 
DIR_CNTRL_rAT.4       (MSG 

USE? ID 

p  S^N*  M' 

FILE_SIZE) 

Ireturns  dir  pathname »  dir  su-cc  code! 

IE  DIR_SUCC_"6^  =  TRUE 
THEN 

MAIL_BOX.MSC-.IMST    :=    STORE_EILE 
MAILJBOX  .MS"  .P^T^NAM*    •-    DIR    PATHNAME 
MAIL_30X.MSG.EILE_SIZE    :=    EILE_SIZE 
MAlL~BOX.MSG.SUCC_CODE    :=    MULL 
t    :=    C-aTT^P^R  .TICKET    'MAIL_POX,    C) 
GATEKEEPER. ADVANCE    (MAIL   BOX,    C) 
GATEKEEPER. *WA IT    (MAIL_BOX,    C,     (t+2)) 
IE   MAIL   POX.MSG.SUCC_CODE   =   TRU"1: 
THEN 

MS  5    :=   U?DATE_STORE 
BTR    '"NTRL   UPDATE    '^SC- 

USE^ID 

PATHNAME) 
Jupdate   will   not    fail! 
MAIL_3CX.MSG.INST    :=    ACK_HCST 

MAIL_BOX.MSG. PATHNAME    :=   NULL 

MAIL_RCX.MSG.ETLE_SIZT'  t-  NULL 

MAIL~B0X.MSG.SUCC"C0DE  :  =  STORE  COMPLETE 

t  :=  GATEKEEPE'9.  TICKET  (MAIL_B0X,  C) 

GA TEK^EPER . 8 DV A HCV    'msj_  to  7 r      n ) 

GATEKEEPER'.' AWAIT  (MAIL  30X,  C,  (t+2)  ) 
ELSE 

MSIL_BOX.wSG.INST  :=  »r'K_TTOST 

MA IL_30X.MSG. PATHNAME  :=  NULL 

MAIL  POX. MSG. FILE  SIZE  !  =  NULL 

MA^BCX.MSG.SUCC^OE"?  :=  MAIL_30X  .MSG  .SUCC_CCDE 

terror  returned  from  io  process? 
cmd  packet  received:  irnurouer  n-umter  of  data  packets! 

t  :=  GATEKEEPER. TICKET  (MAIL  BOX,  C) 

GATEKEEPER.  8DVANCE  'MML_BOX.  C) 

GATEKEEPER. AWAIT  (MAIL  BOX,  C,  (t+2)) 
EI 
ELSE 

MAIL  BOX  .MSnx.IMST  :=  ?CE_HOST 
MAIL'BOX. MSG. PATHNAME  :=  NULL 
MAIL~BOX. MSG. FILE   SIZE    :=   NULL 

MAIL_BOX.MSG  .SUOC~CODE    :=   'B,RROR_COBE    (DIR_SUCC_CODE) 
!file  not    for^d?    write   access   to   file   not    permitted! 
t     :=   GATEKEFPER. TICKET    fMAIL_BOX,    C) 
GATEKEEPER  .  8T!V  »Nri?    (vaIL    POX,    C) 
GATEKEEPER. AWAIT    (MAIL   BOX,    C,    (t+2)) 
EI 
END    EM    CMD   RNB    STOR?   EIL^ 
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ENTRY 

mss 

DIR 


!ret 
II"  D 

MA 

pi  a 

MA 
!a 


r.i 

ELSE 
MA 

MA 


_RND_REA.D_aCL    ?RO"TTURE 

:=   READ_ACL 
CNTRL_PIRvr,TORY    ( MSG 

USE^.ID 

PATHNAME 

NULL  Ifile  type! 

NULL  faccess  level! 

NULL  !link! 

NULL>    !acl_entryl 
ns   dir   succ   code! 
_SUCC_CODE    =   TRUE 

BCX.MSG.INST    :=   ACK  HOST 
"BOX. MSG. PATHNAME    :  =    NULL 
_"POX.MS^.^IL^_STZ7    :=    NULL 
~BCX.MS&.SUCC~COI5E    :=   ACL_?.EAL_CCM?LET: 

data    trar.sfered    frox    acl_buffer! 
t   acknowledgement    sent! 

GATEKEEPER. TICKET    (MAIL   30X,    C) 
KEEPER . a"DVANCE    (M*IL   BOX^    C) 
ir-r-rpTp  .  fl-,v  ?tt    C  m  .fl  I  L   "^OX,    C,     ft +2)) 


ur 

IR 
EN 

IL 
IL 
IL 
IL 
cl 

OS 

T 


MA 
!  f 


t 
G  A 

5  A 


EI 
WD   EM 


IL   POX. M37. INST    :=    ^.r^   POST 

IL^POX .MSG. PATHNAME    :=  NULL 

IL   BOX.MSG.EILE_SIZE    :=    NULL 

IL_EOX.MS? ,SUCC_CODE    :=    E?ROR_CODE    (DIR_SUCC_CODE ) 

ile  not    found;    read    access    to    directory   file 

r>  f     poT.rni  t 1  5^  J 

:=  GATEKEEPER. TICKET  (MAIL  BOX,  C) 

ip-PTrT^pTp  #  spYtNjrtr    f^aiL_?CX,    C) 

TEKEEPER. AWAIT    (MAIL_BOX,    C.    (t+2)) 
rMD    FN7)    ?EaT3    ACL 
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vm    CMD   END    A  Tit!    trL   ENTRY    PRO^EPUR"7 

ENTRY 

MSG    :=    ADD    ACL_ENTBY 
DIR    CNTRL_DIRECTORY    (MSG 

USERID 


! retur 

IF  DIR 

THEN 

MAIL 

MAIL 

MAIL 

MAIL 

t  :  = 

G  AT7 

GATE 

ELSE 

MAIL 

MAIL 

M*IL 

MAIL 

!fil 

per 

t  :  = 

GATE 

GATE 

EI 

END  FM  C 

PATHNAME 

MULL    .'file    type! 

MULL    !access    level! 

MULL    !  Utile! 

ACL_ENTRD 
is   dir   sue c   code! 
_SUCC_CODE    =    TRUE 

_BCX.MSG.IMST    :=    ACE   HOST 
"BOX. MSG. PATHNAME    r=    NULL 
_^OX.MSG.EILT_SIZ^    :  =    NULL 
_30X.MSG.SUC{TC0DE    :=    ACL_ENTRY_AEEED 

GATEKEEPER. TICKET  (MAIL  BOX,  C) 
KEEPER. ADVANCE  (M«IL  BOXT  C) 
KEEPER. AWAIT  (MAIL_30X,  C,  (t-2)) 

BOX. MSG. INST  :=  ACK  HOST 
_30X. MSG .PATHNAME  :=  NULL 
_BOX.MSG.EILE_SIZE 
~BOX.MSG.SU^C_CODE 
e  vn+    found 5  write 
mi t  ted"  acl_er. try 

rtimTftTnrpir^  .  TI  CE^T 

KEEPER .ADVANCE    (MAIL_BOX7    C) 
KEEPER. 'WAIT    (MAIL_BOX,    C.     ( t +2  ) 


:=  MULL 

?  =  ERROR_CODE  (DIR_SUCC_CODE) 
_ access  to  directory  not 
' n  o  o 1 "  em  x> t  y ! 

'MAIL  TOX,  C) 


ME  HMD  ADD  ACL  ENTRY 
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Ev_CMD_HND__DELETE_ACL_EMTaT  PROCEDURE 
3NTP.Y 

^SG  i  =   D^L^T7  "•PL  ^NTRY 

DIR  CNTRL_DIRECTORY  ("msg 

USEEID 

PATHNAME 

NULL  !fil9_type! 

NULL  !access  level! 

MULL  Jlir.k! 

ACL_ENTRY) 
Ireturns  dir  succ  code! 
IE  DIR  SUCC  COD?  =  TRUV 
THEN' 

MAIL  BOX. MSG. INST  :=  «CK_HCST 
MS.  II  "FOX  .MSG  .  ?  iT^N8  ME  :=  MULL 
MAIL~30X.*MSG. TILE  SIZE  :=  MULL 
MAIL~BOX.MSG.SUCC~CODE  :=  SCL_ENTPY_DELETED 
I     :=  '1«TT'KrT?'rR  .TICKET  'MAIL  ^OX,  C) 
GATEKEEPER. ADVANCE  (MAIL_?OXT  C) 
GATEKEEPER. AW  A  IT  fMAIL  30X,  C,  ft +2)) 
'LS  v 

MAIL_BOX. MSG. INST  :=  »Cr_HOST 
MA IL~30X. MSG. PATHNAME  :=  MULL 
MsiI_ECX  .MSG .TILT_SIZT  •  =  MULL 

MAIL_30X.MSG.SUCC_C0DE  :=  ERRCR_CODE  (DIR_SUCC_COPl 
!file  not  found?  write  access  to  directory  not 
permitted  ! 
t  :=  GATEKEEPER. TICKET  'MAIL_^OX,  C) 
GATEKEEPER .SDV*NCE  f!*!IL_3CX,  C) 
SflTEKEvp^R. .  SW&IT  (MSIL  ^CX  ,  p  ,  ft +2)) 
EI 

END  FM  CMD  HMD  DELETE  » CL  ENTRY 
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EM_CMD_HND_A'°01iT  PROCEDURE 
ENTRY 

MSG  :=  ARORT 
DIR_CNTP.L  UPDATE  (MSG 

USERID 
PATHNAME) 
Isto^e  c^d  ne°^f  to  fres  temporary  file! 

MAIL_?OX. MSG. INST  :=  ACK  ^OST 
MAIL  BOX. MSG. PATHNAME  :=  NULL 
M/IL~BOX.MSG.ETLE_SIZE  :  =  NULL 
MAIL~POX.MSG  .SUCCOR15,  :=  CMP  ARORT IP 
t  :=  GATEKEEPER. TICKET  (MAILBOX,  C) 
GATEKEEPER.  ADVANCE  'MAILBOX.  C  ) 
GATEKEEPER . SWA IT  (MAIL  TOX,  r,     ^+2)) 
END  Fm2cMD_END_A30?.T 

END  EM  COMMAND  HANDLER 
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IC_COMMAND_HANDLER    MODULE 
EXTERNAL 


pr_HND_STORTr    PROCEDURE    fSEG    *  DWORD 

SIZE"  LWORD)    Inumter   cf   bits! 

RETURNS    (PK_SUCC_CODE  BYTE) 

PK_HND_SEND    PRO^CURE    (SEG_#  LWORD 

SIZE  LWOP.D)     !ru.TbQr    cf    bits! 

RETURNS    ■'  PK    Sure    "ODE  ^YTE) 

?E_HNr_ACE_HCST   procedure    (msg         BYTE) 

PILE   TTN'C_SEMTi_^IL7    PROC^UR7    (PATHNAME  STRING 

RETURNS    (EILE_SUCC_CODE  BYTE) 

ElLE_HND_ST0?.EJFILE    PROCEDURE    f?*THN*ME  STRING) 

RETURNS    i'EILE_SUCC_COrE  3YTE) 

I m TERN  AL 

10    CMD    RN7-)    ^ROC^URT 

ENTRY 

t     :=    TICKET    fM»IL_ROX,    C^ 
AWAIT    f'MAIL   BOX,    C,    ( t  +  1)  ^ 
DC 

IE   MiIL_BOX.MSG.INST 

CASE   R^D    CMT)   T^EN    PE   %WD  R?4D    CMD 
CASE   ACKSOST    THEN    ?K_HND~ACE_E0ST 

fM«IL   BOX. MSG. SUCC   CODE) 
CASE    SEND_EIL^    TH^N    mT?_^ND_RE4  D_EI  LE 

(mail~3cx.msg. Pathname 

(  M  fi  I  L_B OX  .  MS  G  .  El  L  E_S  I Z E ) 
r&Sv   STORr_'c,ILT,   THEN    ~ILT,_TTN'n_ST0RT,_'5,lL"!:' 

(mail~box7msg. PATHNAME 
mail"box.msg .PILE  SIZE) 

EI 

t    :=    TICEET    (MAIL_BOX,    C) 
ADVANCE    (MAIL   BOX^    C) 
AWAIT    (MAILJPOX,    C,    ( (t+2) 

CD 
END    IO_CMD_HND 

END    10   COMv»ND   HANDLER 
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